Skip to content

Commit

Permalink
Merge pull request #276 from AndrewMurphy2/checksums
Browse files Browse the repository at this point in the history
Branches in a Nutshell: Use unambiguous checksums
  • Loading branch information
ben authored Aug 4, 2016
2 parents e95aba0 + dbb5fd9 commit e96bfdc
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions book/03-git-branching/sections/nutshell.asc
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
[[_git_branches_overview]]
[[_git_branches_overview]]
=== Branches in a Nutshell

To really understand the way Git does branching, we need to take a step back and examine how Git stores its data.
Expand All @@ -9,7 +9,7 @@ When you make a commit, Git stores a commit object that contains a pointer to th
This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit.
Staging the files checksums each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:

[source,console]
----
Expand Down

0 comments on commit e96bfdc

Please sign in to comment.