Improve formatting and fix some typos

Author: ermshiperete

.gitattributes

@@ -20,4 +20,7 @@
 *.ico binary
 *.snk binary
 *.pdb binary
-*.svg binary
+*.svg binary
+
+# Don't check for trailing whitespace at end of lines in the doc pages
+*.md -whitespace=blank-at-eol

.gitignore

@@ -8,6 +8,7 @@
 # User-specific files
 *.suo
 *.user
+*.userprefs
 *.sln.docstates
 *.pidb
 *.received.txt
@@ -62,7 +63,9 @@ TestResults
 ClientBin
 stylecop.*
 ~$*
+*~
 *.dbmdl
+site/
 Generated_Code #added for RIA/Silverlight projects
 
 # Backup & report files from converting an old project file to a newer

docs/configuration.md

@@ -38,6 +38,7 @@ branches:
 ```
 
 The options in here are:
+
  - `mode`: Same as above
  - `tag`: The pre release tag to use for this branch. Use the value `use-branch-name-as-tag` to use the branch name instead.  
    For example `feature/foo` would become a pre-release tag of `foo` with this value

docs/reference/continuous-delivery.md

@@ -8,7 +8,7 @@ In essence continuous delivery means:
  - Your code is automatically built and tested
  - If any of the automated tests fail, the teams #1 priority is to fix the build
  - If the build is green, the application can be deployed at any time
-   - Ideally the buisiness should make that decision
+   - Ideally the business should make that decision
    - The same artifacts which were built and tested should be deployed
    - That means no rebuilding everything when you are deploying
 

docs/reference/intro-to-semver.md

@@ -10,18 +10,18 @@ Version Promiscuity is the opposite problem, **JsonLibrary** releases _v1.1.0_ w
 
 SemVer introduces conventions about breaking changes into our version numbers so we can safely upgrade dependencies without fear of unexpected breaking changes while still allowing us to upgrade downstream libraries to get new features and bug fixes. The convention is quite simple.
 
-{major}.{minor}.{patch}-{tag}+{buildmetadata}  
-{major} = Only incremented if the release has breaking changes (includes bug fixes which have breaking behavioural changes
-{minor} = Incremented if the release has new non-breaking features
-{patch} = Incremented if the release only contains non-breaking bug fixes
-{tag} = Optional -{tag} denotes a pre-release of the version preceeding
-{buildmetadata} = Options +{buildmetadata} contains additional information about the version, but DOES NOT AFFECT the semantic version preceding it.
+**{major}.{minor}.{patch}-{tag}+{buildmetadata}**  
+**{major}** = Only incremented if the release has breaking changes (includes bug fixes which have breaking behavioural changes)  
+**{minor}** = Incremented if the release has new non-breaking features  
+**{patch}** = Incremented if the release only contains non-breaking bug fixes  
+**{tag}** = Optional -{tag} denotes a pre-release of the version preceeding  
+**{buildmetadata}** = Options +{buildmetadata} contains additional information about the version, but DOES NOT AFFECT the semantic version preceding it.
 
 Only one number should be incremented per release, and all lower parts should be reset to 0 (if major is incrememented then minor and patch should become 0).
 
-For a more complete explaination checkout [semver.org](http://semver.org) which is the official spec. Remember this is a breif introduction and does not cover all parts of semantic versioning, just the important parts to get started.
+For a more complete explaination checkout [semver.org](http://semver.org) which is the official spec. Remember this is a brief introduction and does not cover all parts of semantic versioning, just the important parts to get started.
 
 ## SemVer in GitVersion
 GitVersion makes it easy to follow semantic versioning in your library by automatically calculating the next semantic version which your library/application is likely to use. In GitFlow the develop branch will bump the *minor* when master is tagged, while GitHubFlow will bump the *patch*.
 
-Because one side does not always fit all, GitVersion provides many [Variables](../more-info/variables.md) for you to use which contain different variations of the version. For example SemVer will be in the format {major}.{minor}.{patch}-{tag}, but FullSemVer will also include build metadata: {major}.{minor}.{patch}-{tag}+{buildmetadata}
+Because one side does not always fit all, GitVersion provides many [Variables](../more-info/variables.md) for you to use which contain different variations of the version. For example `SemVer` will be in the format {major}.{minor}.{patch}-{tag}, but `FullSemVer` will also include build metadata: {major}.{minor}.{patch}-{tag}+{buildmetadata}

docs/why.md

@@ -2,6 +2,7 @@
 GitVersion makes versioning woes a thing of the past. It looks at your git history to calculate what the version currently is. I have seen and used many different approaches in the past, all have downfalls and often are not transportable between projects.
 
 It solves:
+
  - Rebuilding tags always produces the same version
  - Not having to rebuild to increment versions
  - Not duplicating version information in multiple places (branch release/2.0.0 already has the version in it, why do I need to change something else)