anchor.diff:  This tells us that our repository has been created, and we are on the first commit.  It also mentions what branch we are on.  Typically the default branch is _master_.  For now we won't worry too much about branches, just know we are working with the _master_ branch.
   
   ====== Add
  -You can see in out status report that our `index.html` file is untracked.  This means that it is not yet under version control. The status message gives the advice to _add_ the file so we can include it in the next commit.
  +You can see in out status report that our `index.html` file is untracked.  This means that it is not yet under version control. The status message gives the advice to _add_ the file so we can include it in the next commit.  We can do so by running:
   ```
   $>git add index.html
   
  
positive.code: 
  	new file:   index.html
  ```
  Our index.html file is now ready to be committed.
  
  TIP: If you have a lot of files to add you can run `git add -A` to stage everything for the next commit.
  
  ====== Commit
  Think of commits as a page in your working histroy. Commits are the bread and butter of version control.  These are the markers that you can go back to, your crumb trail in the forest.  When your files have reached a state that is notible, you should do a commit. Notibly, the _initial commit_ kicks everything off, all of your files should be added, and we mark this as the starting point of our _working history_.  *Each commit must have an accompanying commit message.* This is usually a short blurb describing what changes have happened. We can do this all in one command with the `-m` option.
  ```
  $>git commit -m"initial commit"
  [master (root-commit) 5cc9a38] initial commit
  
negative.code: On branch master
  nothing to commit, working directory clean
  ```
  Commits should be made whenever there are clear divisions of work being done, or at landmark places you would like to remember. You have just completed a small task or feature, commit. You've cleaned up spacing in your code, commit. You've added a bunch of comments to your code, good for you, commit! You've done some file restructuring in your directory, commit. You finally debugged that weird problem, commit!  You get the idea...  It is better to commit too much than to little, use them liberally and keep the messages short but meaningful.  Remember, each commit is a single crumb in your breadcrumb trail.
  
  As an example of this workflow, open your `index.html` file in your text editor, and make some changes. It's not important what you change, just change something. Add a new `<h2>` text, remove some paragraphs, etc. When you are done save your changes and jump back to your terminal window.
  ```
  