add some command line examples

Author: schacon

book/03-git-branching/1-git-branching.asc

@@ -1,4 +1,5 @@
-== Git Branching
+[[_git_branching]]
+== Git Branching(((git, branching)))
 
 Nearly every VCS has some form of branching support.
 Branching means you diverge from the main line of development and continue to do work without messing with that main line.
@@ -7,15 +8,17 @@ In many VCS tools, this is a somewhat expensive process, often requiring you to
 Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community.
 Why is it so special?
 The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast.
-Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day.
-Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop.
+Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day.
+Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.
 
-=== What a Branch Is
+=== 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.
-As you may remember from <<_getting_started>>, Git doesn't store data as a series of changesets or deltas, but instead as a series of snapshots.
 
-When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
+As you may remember from <<_getting_started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots.
+
+When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged.
+This object also contains the authors name and email, the message that you typed, and pointers to the commit or commits that directly came bfore this commit (it's 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:
@@ -44,9 +47,16 @@ The default branch name in Git is `master`.
 As you start making commits, you're given a master branch that points to the last commit you made.
 Every time you commit, it moves forward automatically.
 
+[NOTE]
+====
+The ``master'' branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the `git init` command creates it by default and most people don't bother to change it.
+====
+
 .A branch and its commit history
 image::images/18333fig0303-tn.png[A branch and its commit history.]
 
+==== Creating a new branch
+
 What happens if you create a new branch?
 Well, doing so creates a new pointer for you to move around.
 Let's say you create a new branch called testing.
@@ -72,6 +82,20 @@ The `git branch` command only _created_ a new branch – it didn't switch to tha
 .HEAD pointing to a branch
 image::images/18333fig0305-tn.png[HEAD pointing to a branch.]
 
+You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`.
+
+[source,shell]
+----
+$ git log --oneline --decorate
+f30ab (HEAD, master, testing) add feature #32 - ability to add new formats to the central library
+34ac2 fixed bug #1328 - stack overflow under certain conditions
+98ca9 initial commit of my project
+----
+
+You can see the ``master'' and ``testing'' branches that are right there next to the `f30ab` commit.
+
+==== Switching branches
+
 To switch to an existing branch, you run the `git checkout` command.
 Let's switch to the new testing branch:
 
@@ -129,6 +153,19 @@ And you did all that with simple `branch`, `checkout`, and `commit` commands.
 .Divergent history
 image::images/18333fig0309-tn.png[Divergent history.]
 
+You can also see this easily with the `git log` command. If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.
+
+[source,shell]
+----
+$ git log --oneline --decorate --graph --all
+* e6a539b (HEAD, master) made other changes
+| * a41d33e (testing) made a change
+|/
+* b1d18f0 add feature #32 - ability to add new formats to the central library
+* 9eb453a fixed bug #1328 - stack overflow under certain conditions
+* b8a510a initial commit of my project
+----
+
 Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy.
 Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).