Cleaned up markdown in README files

Mostly fixing markdown-lint errors

Author: JKrag

3-way-merge/README.md

@@ -5,6 +5,7 @@
 1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
 
 ## The task
+
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 
 1. Create a branch called greeting and check it out
@@ -20,6 +21,7 @@ You again live in your own branch, this time we will be doing a bit of juggling
 11. What is the output of `git log --oneline --graph --all` now? Observe the extra merge commit created with the message "Merge branch 'greeting'".
 
 ## Useful commands
+
 - `git branch`
 - `git branch <branch-name>`
 - `git branch -d <branch-name>`

README.md

@@ -174,7 +174,9 @@ There is a very small test that you can run in powershell or bash.
 It is contained in the scripts `test.sh` and `test.ps1`.
 
 ### Cleanup
+
 You can remove testing artifacts, `exercise` directories, with the git clean command:
+
 ```sh
 git clean -ffdX
 ```

basic-branching/README.md

@@ -1,9 +1,11 @@
 # Git Kata: Basic Branching
-## Setup:
+
+## Setup
 
 1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
 
 ## The task
+
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 Hint: `git switch` and `git checkout` will make you switch from one branch to another.
 
@@ -27,6 +29,7 @@ Hint: `git switch` and `git checkout` will make you switch from one branch to an
 18. Use `git diff mybranch master` to see the difference between the two branches.
 
 ## Useful commands
+
 - `git switch`
 - `git checkout`
 - `git checkout -b`

basic-staging/README.md

@@ -3,6 +3,7 @@
 This kata will examine the staging area of git.
 
 In git we are working with three different areas:
+
 * The working directory where you are making your changes
 * The staging area where all changes you have added through `git add` will stay
 * The repository where every commit ends up, making your history. To put your staged changes in here you issue the `git commit` command.
@@ -12,7 +13,7 @@ These changes do not have to be the same.
 
 We will also work with `git reset` to reset the staged changes of a file, and `git checkout` to return a file to a previous state.
 
-## Setup:
+## Setup
 
 1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
 
@@ -43,8 +44,6 @@ You live in your own repository. There is a file called `file.txt`.
 21. What is the content of `file.txt`?
 22. What does `git status` tell us?
 
-
-
 ## Useful commands
 
 - `git add`
@@ -56,7 +55,7 @@ You live in your own repository. There is a file called `file.txt`.
 - `git log -n 5`
 - `git log --oneline`
 - `git log --oneline --graph`
-- `git reset HEAD `
+- `git reset HEAD`
 - `git checkout`
 
 ## Aliases

commit-on-wrong-branch/README.md

@@ -1,20 +1,23 @@
 # gitkatas
-## Setup:
+
+## Setup
 
 1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
 
 ## Kata 5: Commit on wrong branch
+
 This kata was shameless ripped off from [Git Katas](http://blog.schauderhaft.de/gitkata/)
 
-You are working really hard on the master branch. 
+You are working really hard on the master branch.
 Part of your work is already committed. This is when your boss comes in with an urgent request.
 
 Since your current HEAD is not ready for prime time you backup one commit, and start a new branch named 'quickfix'. You do whatever your boss wants and commit the changes to that new branch.
 
 That's when you realize you created a minor mess with your branches.
 
 Currently your commits look like this
-```
+
+```text
          master
            |
            v
@@ -25,8 +28,10 @@ remote     ^
            |
         quickfix
 ```
+
 But you want it to look like this:
-```
+
+```text
          remote
            |
            v
@@ -38,19 +43,20 @@ But you want it to look like this:
 
 Git ahead!
 
-Note: since the B in the current and in the target structure don't have the same parent they can't be literally the same commit.
+Note: since the `B` in the current and in the target structure don't have the same parent they can't be literally the same commit.
 
 ## The task
 
 1. Use `git log --oneline --graph --all` to view all the branches and their commits.
-2. Copy C onto master before B by rebasing quickfix on master.
-3. Make a new branch (changes-including-B) off of our master so we can keep working on B.
-4. Reset the HEAD on master back to C.
-5. Delete the quickfix branch.
-6. Push master. You can't do this in the training exercise.
-7. You can merge the changes-including-B branch to master and delete changes-including-B or just checkout changes-including-B and work there.
+2. Copy `C` onto `master` before `B` by rebasing `quickfix` on `master`.
+3. Make a new branch (`changes-including-B`) off of our `master` so we can keep working on `B`.
+4. Reset `master` back to `C`.
+5. Delete the `quickfix` branch.
+6. Push `master`. You can't do this in the training exercise.
+7. You can merge the `changes-including-B` branch to `master` and delete `changes-including-B` or just switch to `changes-including-B` and work there.
 
 ## Useful commands
+
 - `git log --oneline --graph --all`
 - `git checkout <branch-name>`
 - `git rebase <branch-name>`

ff-merge/README.md

@@ -1,5 +1,6 @@
 # Git Kata: Fast-forward Merge
-## Setup:
+
+## Setup
 
 1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
 
@@ -15,16 +16,17 @@ You again live in your own branch, this time we will be doing a bit of juggling
 6. What is the output of `git branch`?
 7. What is the output of `git log --oneline --graph --all`
 
-*Remember: you want to pull in the commit on the feature branch into master. The command 'git merge [branch name]' takes one branch as argument from which it takes commits. The commits are applied to the branch pointed to by HEAD (currently checked out branch).*
+   *Remember: you want to pull in the commit on the feature branch into master. The command 'git merge [branch name]' takes one branch as argument from which it takes commits. The commits are applied to the branch pointed to by HEAD (currently checked out branch).*
 
 8. Checkout `master` branch
-9.  Use `cat` to see the contents of the greetings
+9. Use `cat` to see the contents of the greetings
 10. Diff the branches
 11. Merge the branches
 12. Use `cat` to see the contents of the greetings
 13. Delete the uppercase branch
 
 ## Useful commands
+
 - `git branch`
 - `git branch <branch-name>`
 - `git branch -d <branch-name>`

rebase-branch/README.md

@@ -1,10 +1,11 @@
 # Git Kata: rebase branch
 
-## Setup:
-1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
+## Setup
 
+1. Run `source setup.sh` (or `.\setup.ps1` in PowerShell)
 
 ## The task
+
 You again live in your own branch, this time we will be doing a bit of juggling with branches, to show how lightweight branches are in git.
 
 1. Which branches exist?
@@ -18,6 +19,7 @@ You again live in your own branch, this time we will be doing a bit of juggling
 9. What does the log look like now?
 
 ## Useful commands
+
 - `git checkout <branch-name>`
 - `git rebase <branch-name>`
 - `git log --oneline --graph --all`

reverted-merge/README.md

@@ -29,15 +29,16 @@ features should be included in `mymodule.txt`.
    integrate branch, e.g. change `lib.txt`.
 3. Next we explore how you can get the changes from the branch into the master
    again. First try to merge to see what happens. The `lib.txt` file changes as
-       expected, but '`mymodule.txt` does not. For an in depth discussion of
-       the reason why consult this gist: [Reverting a faulty merge](https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt).
->  reverting a merge commit also
->  undoes the _data_ that the commit changed, but it does absolutely
->  nothing to the effects on _history_ that the merge had.
+   expected, but '`mymodule.txt` does not. For an in depth discussion of
+   the reason why, consult this gist: [Reverting a faulty merge](https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt).
+
+> reverting a merge commit also
+> undoes the _data_ that the commit changed, but it does absolutely
+> nothing to the effects on _history_ that the merge had.
 >
->  So the merge will still exist, and it will still be seen as joining
->  the two branches together, and future merges will see that merge as
->  the last shared state
+> So the merge will still exist, and it will still be seen as joining
+> the two branches together, and future merges will see that merge as
+> the last shared state
 
 4. Undo the merge with a reset --hard
 5. Revert the revert and try the merge again. This time it works.