Skip to content

Commit

Permalink
Merge pull request git#34 from github/about-copy-tweaks
Browse files Browse the repository at this point in the history 
a bunch of copy tweaks
  • Loading branch information
@schacon
schacon committed May 3, 2012
2 parents dfde49f + 8a72e45 commit 5e5a1db
Showing 1 changed file with 45 additions and 51 deletions.
96 changes: 45 additions & 51 deletions app/views/about/index.html.haml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,37 +25,32 @@
%h2 Branching and Merging

%p
Probably Git's most compelling feature that really makes it stand
apart from nearly every other SCM out there is its branching
model.
The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.

%p
Git allows and encourages you to have multiple
local branches that can be entirely independent of each other.
The creation, merging and deletion of those lines of development
take seconds.
Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

%p
This means that you can do things like:

%ul.bullets
%li
<strong>Frictionless Context Switching</strong>. 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.
<strong>Frictionless Context Switching</strong>. 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, and merge it in.
%li
<strong>Role-Based Codelines</strong>. 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
<strong>Role-Based Codelines</strong>. 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
<strong>Feature Based Workflow</strong>. 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.
<strong>Feature Based Workflow</strong>. 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
<strong>Disposable Experimentation</strong>. 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)
<strong>Disposable Experimentation</strong>. 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).

%p.center
<img src="/images/about/branches.png" alt="Branches" />

%p
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 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.
Notably, when you push to a remote repository, you do not have to push all of your branches. You can choose to share just one of your branches, a few of them, or 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.

%p
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.
There are ways to accomplish 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.bottom-nav
=link_to "Small and Fast →", "#", {:class => 'next', 'data-section-id' => 'small-and-fast'}
Expand All @@ -65,15 +60,15 @@
%h2 Small and Fast

%p
<strong>Git is fast</strong>. With Git, nearly all operations are performed locally giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.
<strong>Git is fast</strong>. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

%p
It was also built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of the Git from the start.
Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of the Git from the start.

%h3 Benchmarks

%p
If you don't believe me, let's see how common operations stack up against
Let's see how common operations stack up against
Subversion, a common centralized version control system that is similar
to CVS or Perforce. <em>Smaller is faster.</em>

Expand Down Expand Up @@ -105,15 +100,15 @@
%td
=raw gchart("Size", [['git', 181], ['svn', 132]])
%p
To test, I set up large AWS instances in the same availability zone and
installed Git and SVN on both machines, put the Ruby repository on both
the SVN and Git servers, then did some common operations on both.
For testing, large AWS instances were set up in the same availability zone.
Git and SVN were installed on both machines, the Ruby repository was copied to
both Git and SVN servers, and common operations were performed on both.
%p
In the cases where the commands don't match up exactly, I tried to match
on the lowest common denominator - for example, for the 'commit' tests I
am also including time to push for Git, though most of the time you would
not actually be pushing to the server immediately after a push where you
cannot seperate the two operations in SVN.
In some cases the commands don't match up exactly. Here, matching on the lowest
common denominator was attempted. For example, the 'commit' tests also include
the time to push for Git, though most of the time you would not actually be pushing
to the server immediately after a push where the two commands cannot be separated
in SVN.
%p
All of these times are in seconds.

Expand All @@ -135,20 +130,19 @@
=raw rchart("Blame", [['git', 1.91], ['svn', 3.04]], "Line annotation of a single file (array.c)")

%p
This is basically the best case scenario for SVN - a server with no load with an
Note that this is the best case scenario for SVN - a server with no load with an
80MB/s bandwidth connection to the client machine. Nearly all of these
times would be even worse for SVN if that connection was slower, while
many of the Git times would not be affected.
%p
As you can see, in many of these common version control operations, <strong>Git is
Clearly, in many of these common version control operations, <strong>Git is
one or two orders of magnitude faster than SVN</strong>, even under ideal conditions
for SVN.

%p
A couple of places that Git is slower or bigger is in the initial clone operation
since Git is downloading the entire history rather than only the latest
version. However, as you can see, it's not hugely slower for an operation
that you only ever do once.
One place where Git is slower is in the initial clone operation.
Here, Git is downloading the entire history rather than only the latest
version. As seen in the above charts, it's not considerably slower for an operation
that is only performed once.

%table.benchmarks
%tr
Expand All @@ -161,12 +155,11 @@
=raw trchart("Size (M)", [[nil, nil], ['git', 181], ['svn', 132]], "Size of total client side data and files after clone/checkout (in M)")

%p
It's also interesting to point out the size of the data on the client side
It's also interesting to note that the size of the data on the client side
is very similar even though Git also has every version of every file for the
entire history of the project - this is how efficient it is at compressing
entire history of the project. This illustrates how efficient it is at compressing
and storing data on the client side.


%div.bottom-nav
=link_to "← Branching and Merging", "#", {:class => 'previous', 'data-section-id' => 'branching-and-merging'}
=link_to "Distributed →", "#", {:class => 'next', 'data-section-id' => 'distributed'}
Expand All @@ -175,38 +168,39 @@
%h2 Distributed

%p
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.
One of the nicest features of any Distributed SCM, 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.

%h3 Multiple Backups

%p
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.
This means that even if you're using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.

%h3 Any Workflow

%p
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.
Because of Git's distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.

%h4 Subversion-Style Workflow

%p
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.
A centralized workflow is very common, especially from people transitioning from a centralized system. 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.

%p.center
<img src="/images/about/workflow-a.png" alt="Workflow A" />

%h4 Integration Manager Workflow

%p
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.
Another common Git workflow involves an integration manager — a single person who commits to the 'blessed' repository. A number of developers then 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 often seen with open source or GitHub repositories.

%p.center
<img src="/images/about/workflow-b.png" alt="Workflow B" />

%h4 Dictator and Lieutenants Workflow

%p
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 the push to the 'blessed' repository that everyone then clones from again.
For more massive projects, a development workflow like that of the Linux kernel is often effective.
In this model, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the 'dictator') can pull changes from only his/her lieutenants and then push to the 'blessed' repository that everyone then clones from again.

%p.center
<img src="/images/about/workflow-c.png" alt="Workflow C" />
Expand All @@ -219,19 +213,19 @@
%h2 Data Assurance

%p
The data model that Git uses ensures cryptographic integrity of every bit
of your project. Every file and commit is checksummed and retrieved by it's
checksum when checked back out. It's impossible to get out of Git anything
The data model that Git uses ensures the cryptographic integrity of every bit
of your project. Every file and commit is checksummed and retrieved by its
checksum when checked back out. It's impossible to get anything out of Git
other than the <strong>exact bits you put in</strong>.

%img{:src => "/images/assurance.png"}

%p
It is also impossible to change any file, date, commit message or any other
It is also impossible to change any file, date, commit message, or any other
data in a Git repository without changing the IDs of everything after it.
This means that if you have a commit ID you can not only be assured that
your project is exactly the same as when it was committed, but you can also
be assured that nothing in it's history was changed.
This means that if you have a commit ID, you can be assured not only that
your project is exactly the same as when it was committed, but
that nothing in its history was changed.

%p
Most centralized version control systems provide no such integrity by default.
Expand All @@ -244,19 +238,19 @@
%h2 Staging Area

%p
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.
Unlike the other systems, Git has something called the "staging area" or "index". This is an intermediate area where commits can be formatted and reviewed before completing the commit.

%p
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
One thing that sets Git apart from other tools is that it's possible to quickly stage some of your files and commit them without committing all of the other modified files in your working directory or having to list them on the command line during the commit.

%p.center
<img src="/images/about/index1.png" alt="Index 1" />

%p
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 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.
This 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 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 needed.

%p
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.
Of course, Git also makes it easy to ignore this feature if you don't want that kind of control — just add a '-a' to your commit command in order to add all changes to all files to the staging area.

%p.center
<img src="/images/about/index2.png" alt="Index 2" />
Expand Down

0 comments on commit 5e5a1db

Please sign in to comment.