Added some git best practices.

Author: rdadolf

Git Tutorial.ipynb

@@ -1,7 +1,7 @@
 {
  "metadata": {
   "name": "",
-  "signature": "sha256:ecc85a9f6327da4ad83758adb8f7f947e61643564a6ac93c33224fd94aa38a93"
+  "signature": "sha256:f009d017d43df3cde3f0342f9fc04bcfff7add3063982b55bd3e578d89b4cf18"
  },
  "nbformat": 3,
  "nbformat_minor": 0,
@@ -1201,14 +1201,56 @@
       "----\n",
       "# nbviewer\n",
       "\n",
-      "A final note should go to the eminently useful website http://nbviewer.ipython.org/. You've probably already used this, knowingly or not, to view ipython notebooks from other people.\n",
+      "A note should go to the eminently useful website http://nbviewer.ipython.org/. You've probably already used this, knowingly or not, to view ipython notebooks from other people.\n",
       "\n",
       "What you may not know is that nbviewer can be used to view ipython notebooks directly from your git repository.\n",
       "\n",
       "The easiest way to start is simply by typing in your github username into the search field. This will take you to a very familiar directory navigation page, which you can use to find the repository and notebook you want. I leave it up to you to check out the URL and understand how to craft links directly, but one useful tip is that these links are *permanent*. If you link to your repo using nbviewer, it will automatically display the most recent version of that branch (the branch name is embedded in the URL—and you can change this if you like).\n",
       "\n",
       "One helpful trick is to put an nbviewer link to important notebooks right into your README.md or your project page so your visitors don't have to download or fuss with the notebook themselves."
      ]
+    },
+    {
+     "cell_type": "markdown",
+     "metadata": {},
+     "source": [
+      "----\n",
+      "# Git habits\n",
+      "\n",
+      "** * Commit early, commit often. * **\n",
+      "\n",
+      "Git is more effective when used at a fine granularity. For starters, you can't undo what you haven't committed, so committing lots of small changes makes it easier to find the right rollback point. Also, merging becomes a lot easier when you only have to deal with a handful of conflicts.\n",
+      "\n",
+      "** * Commit unrelated changes separately. * **\n",
+      "\n",
+      "Identifying the source of a bug or understanding the reason why a particular piece of code exists is much easier when commits focus on related changes. Some of this has to do with simplifying commit messages and making it easier to look through logs, but it has other related benefits: commits are smaller and simpler, and merge conflicts are confined to only the commits which actually have conflicting code.\n",
+      "\n",
+      "** * Do not commit binaries and other temporary files. * **\n",
+      "\n",
+      "Git is meant for tracking changes. In nearly all cases, the only meaningful difference between the contents of two binaries is that they are different. If you change source files, compile, and commit the resulting binary, git sees an entirely different file. The end result is that the git repository (which contains a complete history, remember) begins to become bloated with the history of many dissimilar binaries. Worse, there's often little advantage to keeping those files in the history. An argument can be made for periodically snapshotting working binaries, but things like object files, compiled python files, and editor auto-saves are basically wasted space.\n",
+      "\n",
+      "** * Ignore files which should not be committed * **\n",
+      "\n",
+      "Git comes with a built-in mechanism for ignoring certain types of files. Placing filenames or wildcards in a `.gitignore` file placed in the top-level directory (where the `.git` directory is also located) will cause git to ignore those files when checking file status. This is a good way to ensure you don't commit the wrong files accidentally, and it also makes the output of `git status` somewhat cleaner.\n",
+      "\n",
+      "** * Always make a branch for new changes * **\n",
+      "\n",
+      "While it's tempting to work on new code directly in the `master` branch, it's usually a good idea to create a new one instead, especially for team-based projects. The major advantage to this practice is that it keeps logically disparate change sets separate. This means that if two people are working on improvements in two different branches, when they merge, the actual workflow is reflected in the git history. Plus, explicitly creating branches adds some semantic meaning to your branch structure. Moreover, there is very little difference in how you use git.\n",
+      "\n",
+      "** * Write good commit messages * **\n",
+      "\n",
+      "I cannot understate the importance of this.\n",
+      "\n",
+      "** Seriously. Write good commit messages. **"
+     ]
+    },
+    {
+     "cell_type": "code",
+     "collapsed": false,
+     "input": [],
+     "language": "python",
+     "metadata": {},
+     "outputs": []
     }
    ],
    "metadata": {}