fix(README): fixup formatting of the markdown file

no real content changes at this point. just cleaning up the markdown of
the file first.

README.md

@@ -1,8 +1,6 @@
-etcd
-====
-## Overview
+# etcd
 
-## Start with examples
+## Getting Started
 
 ### Setting up a node
 
@@ -25,6 +23,7 @@ curl http://127.0.0.1:4001/v1/keys/message -d value="Hello world"
 ```
 
 This response contains five fields. We will introduce three more fields as we try more commands.
+
 1. The action of the request; we set the value via a POST request, thus the action is `SET`.
  
 2. The key of the request; we set `/message` to `Hello world!`, so the key field is `/message`.
@@ -34,8 +33,7 @@ Notice we use a file system like structure to represent the key-value pairs. So
 
 4. If we set a new key; `/message` did not exist before, so this is a new key.
 
-5. Index field is the unique request index of the set request. Each sensitive request we send to the server will have a unique request index. The current sensitive request are `SET`, `DELETE` and `TESTANDSET`. All of these request will change the state of the key-value store system, thus they are sensitive. `GET`, `LIST` and `WATCH` are non-sensitive commands. Those commands will not change the state of the key-value store system. 
-You may notice that in this example the index is 3, although it is the first request you sent to the server. This is because there are some internal commands that also change the state of the server, we also need to assign them command indexes(Command used to add a server and sync the servers).
+5. Index field is the unique request index of the set request. Each sensitive request we send to the server will have a unique request index. The current sensitive request are `SET`, `DELETE` and `TESTANDSET`. All of these request will change the state of the key-value store system, thus they are sensitive. `GET`, `LIST` and `WATCH` are non-sensitive commands. Those commands will not change the state of the key-value store system. You may notice that in this example the index is 3, although it is the first request you sent to the server. This is because there are some internal commands that also change the state of the server, we also need to assign them command indexes(Command used to add a server and sync the servers).
 
 #### Getting the value of a key
 
@@ -44,6 +42,7 @@ curl http://127.0.0.1:4001/v1/keys/message
 ```
 
 You should receive the response as
+
 ```json
 {"action":"GET","key":"/message","value":"Hello world","index":3}
 ```
@@ -109,6 +108,7 @@ which indicates the key has expired and was deleted.
 Watch command can watch as a prefix path and get notification if any key changes after the prefix.
 
 In one terminal, we send a watch request:
+
 ```sh
 curl http://127.0.0.1:4001/v1/watch/foo
 ```
@@ -147,11 +147,13 @@ What it does is to test whether the given previous value is equal to the value o
 
 Here is a simple example.
 Let us create a key-value pair first: `testAndSet=one`.
+
 ```sh
 curl http://127.0.0.1:4001/v1/keys/testAndSet -d value=one
 ```
 
 Let us try a invaild `TestAndSet` command.
+
 ```sh
 curl http://127.0.0.1:4001/v1/testAndSet/testAndSet -d prevValue=two -d value=three
 ```
@@ -159,6 +161,7 @@ curl http://127.0.0.1:4001/v1/testAndSet/testAndSet -d prevValue=two -d value=th
 This will try to test if the previous of the key is two, it is change it to three.
 
 The response should be
+
 ```html
 Test one==two fails
 ```
@@ -181,6 +184,7 @@ We successfully change the value from “one” to “two”, since we give the
 
 
 #### Listing directory
+
 Last we provide a simple List command to list all the keys under a prefix path.
 
 Let us create some keys first.
@@ -208,6 +212,7 @@ We should see the response as
 which meas `foo=barbar` is a key-value pair under `/foo` and `foo_dir` is a directory.
 
 ### Setting up a cluster of three machines
+
 Next we can explore the power of etcd cluster. We use go-raft as the underlay distributed protocol which provide consistency and persistence of all the machines in the cluster. The will allow if the minor machine dies, the cluster will still be able to performance correctly. Also if most of the machines dead and restart,  we will recover from the previous state of the cluster.
 
 Let us create 3 new machines.
@@ -223,11 +228,13 @@ We use -s to specify server port and -c to specify client port and -d to specify
 We use -C to specify the Cluster
 
 Let the second one join it.
+
 ```sh
 ./etcd -c 4002 -s 7002 -C 127.0.0.1:7001 -d nod/node2
 ```
 
 And the third one:
+
 ```sh
 ./etcd -c 4003 -s 7003 -C 127.0.0.1:7001 -d nod/node3
 ```
@@ -263,10 +270,12 @@ It succeed!
 OK. Next let us kill all the nodes to test persistence. And restart all the nodes use the same command before.
 
 Try
+
 ```sh
 curl http://127.0.0.1:4002/v1/keys/foo
 ```
 You should able to see
+
 ```json
 {"action":"GET","key":"/foo","value":"bar","index":5}
 ```