Use blockquotes for quotes

git.md

@@ -17,27 +17,25 @@ Commit messages should contain:
 
 Taken from [Tim Pope’s guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 
-    Capitalized, short (50 chars or less) summary
+> Capitalized, short (50 chars or less) summary
 
-    More detailed explanatory text, if necessary.  Wrap it to about 72
-    characters or so.  In some contexts, the first line is treated as the
-    subject of an email and the rest of the text as the body.  The blank
-    line separating the summary from the body is critical (unless you omit
-    the body entirely); tools like rebase can get confused if you run the
-    two together.
+> More detailed explanatory text, if necessary.  Wrap it to about 72
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); tools like rebase can get confused if you run the
+two together.
 
-    Write your commit message in the present tense: "Fix bug" and not "Fixed
-    bug."  This convention matches up with commit messages generated by
-    commands like git merge and git revert.
+> Write your commit message in the present tense: "Fix bug" and not "Fixed
+bug."  This convention matches up with commit messages generated by
+commands like git merge and git revert.
 
-    Further paragraphs come after blank lines.
+> Further paragraphs come after blank lines.
 
-    - Bullet points are okay, too
-
-    - Typically a hyphen or asterisk is used for the bullet, preceded by a
-      single space, with blank lines in between, but conventions vary here
-
-    - Use a hanging indent
+> - Bullet points are okay, too
+> - Typically a hyphen or asterisk is used for the bullet, preceded by a
+  single space, with blank lines in between, but conventions vary here
+> - Use a hanging indent
 
 ## Branching/merging conventions