migrated tons more content from the user guide and tutorials - about time to edit

Author: schacon

assets/stylesheets/style.css

@@ -59,3 +59,5 @@ table tr td { vertical-align: top;}
 
 table.data-table tr td { vertical-align: top;}
 table.data-table tr td h3 { background: #B5463F; color: #fff; padding: 5px; }
+
+pre { background: #eee; padding: 5px;}

layout/second.css

@@ -162,7 +162,7 @@ table.lined td, table.lined th {
 @page :left {
   @top-left {
     font: 11pt "Gill Sans", serif;
-    content: "Ruby on Rails 2.1 - What's New";
+    content: "Git Community Book";
     vertical-align: bottom;
     padding-bottom: 2em;
   }

text/07_Normal_Workflow/0_ Normal_Workflow.markdown

@@ -1,3 +1,56 @@
 ## Normal Workflow ##
 
-(modifying, adding, commiting)
+Modify some files, then add their updated contents to the index:
+
+    $ git add file1 file2 file3
+
+You are now ready to commit.  You can see what is about to be committed
+using linkgit:git-diff[1] with the --cached option:
+
+    $ git diff --cached
+
+(Without --cached, linkgit:git-diff[1] will show you any changes that
+you've made but not yet added to the index.)  You can also get a brief
+summary of the situation with linkgit:git-status[1]:
+
+    $ git status
+    # On branch master
+    # Changes to be committed:
+    #   (use "git reset HEAD <file>..." to unstage)
+    #
+    #	modified:   file1
+    #	modified:   file2
+    #	modified:   file3
+    #
+
+If you need to make any further adjustments, do so now, and then add any
+newly modified content to the index.  Finally, commit your changes with:
+
+    $ git commit
+
+This will again prompt your for a message describing the change, and then
+record a new version of the project.
+
+Alternatively, instead of running `git add` beforehand, you can use
+
+    $ git commit -a
+    
+which will automatically notice any modified (but not new) files, add
+them to the index, and commit, all in one step.
+
+A note on commit messages: Though not required, it's a good idea to
+begin the commit message with a single short (less than 50 character)
+line summarizing the change, followed by a blank line and then a more
+thorough description.  Tools that turn commits into email, for
+example, use the first line on the Subject: line and the rest of the
+commit in the body.
+
+
+#### Git tracks content not files ####
+
+Many revision control systems provide an "add" command that tells the
+system to start tracking changes to a new file.  Git's "add" command
+does something simpler and more powerful: `git add` is used both for new
+and newly modified files, and in both cases it takes a snapshot of the
+given files and stages that content in the index, ready for inclusion in
+the next commit.

text/08_Basic_Branching_and_Merging/0_ Basic_Branching_and_Merging.markdown

@@ -1 +1,164 @@
-##Basic Branching and Merging
+## Basic Branching and Merging ##
+
+A single git repository can maintain multiple branches of
+development.  To create a new branch named "experimental", use
+
+    $ git branch experimental
+
+If you now run
+
+    $ git branch
+
+you'll get a list of all existing branches:
+
+      experimental
+    * master
+
+The "experimental" branch is the one you just created, and the
+"master" branch is a default branch that was created for you
+automatically.  The asterisk marks the branch you are currently on;
+type
+
+    $ git checkout experimental
+
+to switch to the experimental branch.  Now edit a file, commit the
+change, and switch back to the master branch:
+
+    (edit file)
+    $ git commit -a
+    $ git checkout master
+
+Check that the change you made is no longer visible, since it was
+made on the experimental branch and you're back on the master branch.
+
+You can make a different change on the master branch:
+
+    (edit file)
+    $ git commit -a
+
+at this point the two branches have diverged, with different changes
+made in each.  To merge the changes made in experimental into master, run
+
+    $ git merge experimental
+
+If the changes don't conflict, you're done.  If there are conflicts,
+markers will be left in the problematic files showing the conflict;
+
+    $ git diff
+
+will show this.  Once you've edited the files to resolve the
+conflicts,
+
+    $ git commit -a
+
+will commit the result of the merge. Finally,
+
+    $ gitk
+
+will show a nice graphical representation of the resulting history.
+
+At this point you could delete the experimental branch with
+
+    $ git branch -d experimental
+
+This command ensures that the changes in the experimental branch are
+already in the current branch.
+
+If you develop on a branch crazy-idea, then regret it, you can always
+delete the branch with
+
+    $ git branch -D crazy-idea
+
+Branches are cheap and easy, so this is a good way to try something
+out.
+
+### How to merge ###
+
+You can rejoin two diverging branches of development using
+linkgit:git-merge[1]:
+
+    $ git merge branchname
+
+merges the development in the branch "branchname" into the current
+branch.  If there are conflicts--for example, if the same file is
+modified in two different ways in the remote branch and the local
+branch--then you are warned; the output may look something like this:
+
+    $ git merge next
+     100% (4/4) done
+    Auto-merged file.txt
+    CONFLICT (content): Merge conflict in file.txt
+    Automatic merge failed; fix conflicts and then commit the result.
+
+Conflict markers are left in the problematic files, and after
+you resolve the conflicts manually, you can update the index
+with the contents and run git commit, as you normally would when
+creating a new file.
+
+If you examine the resulting commit using gitk, you will see that it
+has two parents, one pointing to the top of the current branch, and
+one to the top of the other branch.
+
+### Resolving a merge ###
+
+When a merge isn't resolved automatically, git leaves the index and
+the working tree in a special state that gives you all the
+information you need to help resolve the merge.
+
+Files with conflicts are marked specially in the index, so until you
+resolve the problem and update the index, linkgit:git-commit[1] will
+fail:
+
+    $ git commit
+    file.txt: needs merge
+
+Also, linkgit:git-status[1] will list those files as "unmerged", and the
+files with conflicts will have conflict markers added, like this:
+
+    <<<<<<< HEAD:file.txt
+    Hello world
+    =======
+    Goodbye
+    >>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+
+All you need to do is edit the files to resolve the conflicts, and then
+
+    $ git add file.txt
+    $ git commit
+
+Note that the commit message will already be filled in for you with
+some information about the merge.  Normally you can just use this
+default message unchanged, but you may add additional commentary of
+your own if desired.
+
+The above is all you need to know to resolve a simple merge.  But git
+also provides more information to help resolve conflicts:
+
+### Undoing a merge ###
+
+If you get stuck and decide to just give up and throw the whole mess
+away, you can always return to the pre-merge state with
+
+    $ git reset --hard HEAD
+
+Or, if you've already committed the merge that you want to throw away,
+
+    $ git reset --hard ORIG_HEAD
+
+However, this last command can be dangerous in some cases--never
+throw away a commit you have already committed if that commit may
+itself have been merged into another branch, as doing so may confuse
+further merges.
+
+### Fast-forward merges ###
+
+There is one special case not mentioned above, which is treated
+differently.  Normally, a merge results in a merge commit, with two
+parents, one pointing at each of the two lines of development that
+were merged.
+
+However, if the current branch is a descendant of the other--so every
+commit present in the one is already contained in the other--then git
+just performs a "fast forward"; the head of the current branch is moved
+forward to point at the head of the merged-in branch, without any new
+commits being created.

text/09_Reviewing_History_Git_Log/0_ Reviewing_History_Git_Log.markdown

@@ -1,2 +1,33 @@
 ## Reviewing History - Git Log ##
 
+The linkgit:git-log[1] command can show lists of commits.  On its
+own, it shows all commits reachable from the parent commit; but you
+can also make more specific requests:
+
+    $ git log v2.5..	# commits since (not reachable from) v2.5
+    $ git log test..master	# commits reachable from master but not test
+    $ git log master..test	# ...reachable from test but not master
+    $ git log master...test	# ...reachable from either test or master,
+    			#    but not both
+    $ git log --since="2 weeks ago" # commits from the last 2 weeks
+    $ git log Makefile      # commits which modify Makefile
+    $ git log fs/		# ... which modify any file under fs/
+    $ git log -S'foo()'	# commits which add or remove any file data
+    			# matching the string 'foo()'
+
+And of course you can combine all of these; the following finds
+commits since v2.5 which touch the Makefile or any file under fs:
+
+    $ git log v2.5.. Makefile fs/
+
+You can also ask git log to show patches:
+
+    $ git log -p
+
+See the "--pretty" option in the linkgit:git-log[1] man page for more
+display options.
+
+Note that git log starts with the most recent commit and works
+backwards through the parents; however, since git history can contain
+multiple independent lines of development, the particular order that
+commits are listed in may be somewhat arbitrary.

text/10_Comparing_Commits_Git_Diff/0_ Comparing_Commits_Git_Diff.markdown

@@ -1,2 +1,13 @@
 ## Comparing Commits - Git Diff ##
 
+You can generate diffs between any two versions using
+linkgit:git-diff[1]:
+
+    $ git diff master..test
+
+That will produce the diff between the tips of the two branches.  If
+you'd prefer to find the diff from their common ancestor to test, you
+can use three dots instead of two:
+
+    $ git diff master...test
+