Merge branch 'docs-lists-cleanup-3' into 'master'

Adjust headers in /university

See merge request gitlab-org/gitlab-ce!31702

doc/topics/autodevops/index.md

@@ -816,7 +816,7 @@ To configure your application variables:
 
 1. Create a CI Variable, ensuring the key is prefixed with
    `K8S_SECRET_`. For example, you can create a variable with key
-`K8S_SECRET_RAILS_MASTER_KEY`.
+   `K8S_SECRET_RAILS_MASTER_KEY`.
 
 1. Run an Auto Devops pipeline either by manually creating a new
    pipeline or by pushing a code change to GitLab.
@@ -1017,10 +1017,10 @@ Everything behaves the same way, except:
 
 - It's enabled by setting the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
 - Instead of the standard `production` job, the following jobs with a 5 minute delay between each are created:
-    1. `timed rollout 10%`
-    1. `timed rollout 25%`
-    1. `timed rollout 50%`
-    1. `timed rollout 100%`
+  1. `timed rollout 10%`
+  1. `timed rollout 25%`
+  1. `timed rollout 50%`
+  1. `timed rollout 100%`
 
 ## Currently supported languages
 

doc/university/training/end-user/README.md

@@ -9,12 +9,8 @@ which can be found at [End User Slides](https://gitlab-org.gitlab.io/end-user-tr
 through it's [RevealJS](https://gitlab.com/gitlab-org/end-user-training-slides)
 project.
 
----
-
 ## Git Intro
 
----
-
 ### What is a Version Control System (VCS)
 
 - Records changes to a file
@@ -22,8 +18,6 @@ project.
 - Disaster Recovery
 - Types of VCS: Local, Centralized and Distributed
 
----
-
 ### Short Story of Git
 
 - 1991-2002: The Linux kernel was being maintained by sharing archived files
@@ -31,8 +25,6 @@ project.
 - 2002: The Linux kernel project began using a DVCS called BitKeeper
 - 2005: BitKeeper revoked the free-of-charge status and Git was created
 
----
-
 ### What is Git
 
 - Distributed Version Control System
@@ -42,8 +34,6 @@ project.
 - Disaster recovery friendly
 - Open Source
 
----
-
 ### Getting Help
 
 - Use the tools at your disposal when you get stuck.
@@ -51,14 +41,10 @@ project.
   - Use Google (i.e. StackOverflow, Google groups)
   - Read documentation at <https://git-scm.com>
 
----
-
 ## Git Setup
 
 Workshop Time!
 
----
-
 ### Setup
 
 - Windows: Install 'Git for Windows'
@@ -69,8 +55,6 @@ Workshop Time!
   - Debian: `sudo apt-get install git-all`
   - Red Hat `sudo yum install git-all`
 
----
-
 ### Configure
 
 - One-time configuration of the Git client:
@@ -91,16 +75,12 @@ git config --global --list
 - You might want or be required to use an SSH key.
   - Instructions: [SSH](http://doc.gitlab.com/ce/ssh/README.html)
 
----
-
 ### Workspace
 
 - Choose a directory on you machine easy to access
 - Create a workspace or development directory
 - This is where we'll be working and adding content
 
----
-
 ```bash
 mkdir ~/development
 cd ~/development
@@ -111,12 +91,8 @@ mkdir ~/workspace
 cd ~/workspace
 ```
 
----
-
 ## Git Basics
 
----
-
 ### Git Workflow
 
 - Untracked files
@@ -128,8 +104,6 @@ cd ~/workspace
 - Upstream
   - Hosted repository on a shared server
 
----
-
 ### GitLab
 
 - GitLab is an application to code, test and deploy.
@@ -137,8 +111,6 @@ cd ~/workspace
   issue tracking, Merge Requests, and other features.
 - The hosted version of GitLab is gitlab.com
 
----
-
 ### New Project
 
 - Sign in into your gitlab.com account
@@ -146,8 +118,6 @@ cd ~/workspace
 - Choose to import from 'Any Repo by URL' and use <https://gitlab.com/gitlab-org/training-examples.git>
 - On your machine clone the `training-examples` project
 
----
-
 ### Git and GitLab basics
 
 1. Edit `edit_this_file.rb` in `training-examples`
@@ -158,8 +128,6 @@ cd ~/workspace
 1. Push the commit to the remote
 1. View the git log
 
----
-
 ```shell
 # Edit `edit_this_file.rb`
 git status
@@ -170,8 +138,6 @@ git push origin master
 git log
 ```
 
----
-
 ### Feature Branching
 
 1. Create a new feature branch called `squash_some_bugs`
@@ -179,8 +145,6 @@ git log
 1. Commit
 1. Push
 
----
-
 ```shell
 git checkout -b squash_some_bugs
 # Edit `bugs.rb`
@@ -190,14 +154,8 @@ git commit -m 'Fix some buggy code'
 git push origin squash_some_bugs
 ```
 
----
-
 ## Merge Request
 
----
-
-### Merge requests
-
 - When you want feedback create a merge request
 - Target is the ‘default’ branch (usually master)
 - Assign or mention the person you would like to review
@@ -206,8 +164,6 @@ git push origin squash_some_bugs
 - Anyone can comment, not just the assignee
 - Push corrections to the same branch
 
----
-
 ### Merge request example
 
 - Create your first merge request
@@ -216,8 +172,6 @@ git push origin squash_some_bugs
   - Push a new commit to the same branch
   - Review the changes again and notice the update
 
----
-
 ### Feedback and Collaboration
 
 - Merge requests are a time for feedback and collaboration
@@ -230,24 +184,17 @@ git push origin squash_some_bugs
 
 ---
 
-- Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:[Thoughtbot](https://github.com/thoughtbot/guides/tree/master/code-review)
+- Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:
+  [Thoughtbot](https://github.com/thoughtbot/guides/tree/master/code-review)
 - See GitLab merge requests for examples: [Merge Requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests)
 
----
-
 ## Merge Conflicts
 
----
-
-### Merge Conflicts
-
 - Happen often
 - Learning to fix conflicts is hard
 - Practice makes perfect
 - Force push after fixing conflicts. Be careful!
 
----
-
 ### Example Plan
 
 1. Checkout a new branch and edit conflicts.rb. Add 'Line4' and 'Line5'.
@@ -261,8 +208,6 @@ git push origin squash_some_bugs
 1. Force push the changes
 1. Finally continue with the Merge Request
 
----
-
 ### Example 1/2
 
 ```sh
@@ -282,8 +227,6 @@ git commit -am "add line6 and line7"
 git push origin master
 ```
 
----
-
 ### Example 2/2
 
 Create a merge request on the GitLab web UI. You'll see a conflict warning.
@@ -305,8 +248,6 @@ git rebase --continue
 git push origin conflicts_branch -f
 ```
 
----
-
 ### Notes
 
 - When to use `git merge` and when to use `git rebase`
@@ -314,12 +255,8 @@ git push origin conflicts_branch -f
 - Merge when bringing changes from feature to master
 - Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/>
 
----
-
 ## Revert and Unstage
 
----
-
 ### Unstage
 
 To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch:
@@ -347,8 +284,6 @@ If we want to remove a file from the repository but keep it on disk, say we forg
 git rm <filename> --cache
 ```
 
----
-
 ### Undo Commits
 
 Undo last commit putting everything back into the staging area:
@@ -377,8 +312,6 @@ git reset --hard HEAD^^
 
 Don't reset after pushing
 
----
-
 ### Reset Workflow
 
 1. Edit file again 'edit_this_file.rb'
@@ -392,8 +325,6 @@ Don't reset after pushing
 1. Pull for updates
 1. Push changes
 
----
-
 ```sh
 # Change file edit_this_file.rb
 git status
@@ -407,8 +338,6 @@ git pull origin master
 git push origin master
 ```
 
----
-
 ### git revert vs git reset
 
 Reset removes the commit while revert removes the changes but leaves the commit
@@ -425,16 +354,10 @@ git revert <rev commit hash>
 # reverted commit is back (new commit created again)
 ```
 
----
-
 ## Questions
 
----
-
 ## Instructor Notes
 
----
-
 ### Version Control
 
 - Local VCS was used with a filesystem or a simple db.

doc/university/training/topics/bisect.md

@@ -4,13 +4,11 @@ comments: false
 
 # Bisect
 
-## Bisect
-
 - Find a commit that introduced a bug
 - Works through a process of elimination
 - Specify a known good and bad revision to begin
 
-## Bisect
+## Bisect sample workflow
 
 1. Start the bisect process
 1. Enter the bad revision (usually latest commit)

doc/university/training/topics/cherry_picking.md

@@ -4,13 +4,11 @@ comments: false
 
 # Cherry Pick
 
-## Cherry Pick
-
 - Given an existing commit on one branch, apply the change to another branch
 - Useful for backporting bug fixes to previous release branches
 - Make the commit on the master branch and pick in to stable
 
-## Cherry Pick
+## Cherry Pick sample workflow
 
 1. Check out a new 'stable' branch from 'master'
 1. Change back to 'master'
@@ -19,8 +17,6 @@ comments: false
 1. Check out the 'stable' branch
 1. Cherry pick the commit using the SHA obtained earlier
 
-## Commands
-
 ```bash
 git checkout master
 git checkout -b stable

doc/university/training/topics/feature_branching.md

@@ -11,15 +11,13 @@ comments: false
 - Push branches to the server frequently
   - Hint: This is a cheap backup for your work-in-progress code
 
-## Feature branching
+## Feature branching sample workflow
 
 1. Create a new feature branch called 'squash_some_bugs'
 1. Edit '`bugs.rb`' and remove all the bugs.
 1. Commit
 1. Push
 
-## Commands
-
 ```sh
 git checkout -b squash_some_bugs
 # Edit `bugs.rb`

doc/university/training/topics/getting_started.md

@@ -35,8 +35,6 @@ comments: false
 1. Create a '`Workspace`' directory in your home directory.
 1. Clone the '`training-examples`' project.
 
-## Commands
-
 ```sh
 mkdir ~/workspace
 cd ~/workspace
@@ -69,8 +67,6 @@ Modified files that have been marked to go in the next commit.
 1. Push the commit to the remote
 1. View the git log
 
-## Commands
-
 ```sh
 # Edit `edit_this_file.rb`
 git status

doc/university/training/topics/git_add.md

@@ -4,8 +4,6 @@ comments: false
 
 # Git Add
 
-## Git Add
-
 Adds content to the index or staging area.
 
 - Adds a list of file:
@@ -20,8 +18,6 @@ Adds content to the index or staging area.
   git add -A
   ```
 
-## Git add continued
-
 - Add all text files in current dir:
 
   ```bash

doc/university/training/topics/merge_conflicts.md

@@ -9,7 +9,7 @@ comments: false
 - Practice makes perfect
 - Force push after fixing conflicts. Be careful!
 
-## Merge conflicts
+## Merge conflicts sample workflow
 
 1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
 1. Commit and push.
@@ -22,8 +22,6 @@ comments: false
 1. Force push the changes.
 1. Finally continue with the Merge Request.
 
-## Commands
-
 ```sh
 git checkout -b conflicts_branch
 

doc/university/training/topics/merge_requests.md

@@ -30,8 +30,6 @@ comments: false
 - Be as receptive as possible
 - Feedback is about the best code, not the person. You are not your code
 
-## Feedback and Collaboration
-
 Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:
 [https://github.com/thoughtbot/guides/tree/master/code-review](https://github.com/thoughtbot/guides/tree/master/code-review)
 

doc/university/training/topics/stash.md

@@ -25,7 +25,7 @@ and we need to change to a different branch.
   git stash apply stash@{3}
   ```
 
-- Every time we save a stash it gets stacked so by using list we can see all our
+- Every time we save a stash it gets stacked so by using `list` we can see all our
   stashes.
 
   ```sh
@@ -54,7 +54,7 @@ and we need to change to a different branch.
 - If we meet conflicts we need to either reset or commit our changes.
 - Conflicts through `pop` will not drop a stash afterwards.
 
-## Git Stash
+## Git Stash sample workflow
 
 1. Modify a file
 1. Stage file
@@ -64,8 +64,6 @@ and we need to change to a different branch.
 1. Apply with pop
 1. View list to confirm changes
 
-## Commands
-
 ```sh
 # Modify edit_this_file.rb file
 git add .

doc/university/training/topics/tags.md

@@ -11,18 +11,12 @@ type: reference
 - Many projects combine an annotated release tag with a stable branch
 - Consider setting deployment/release tags automatically
 
-# Tags
+## Tags sample workflow
 
 - Create a lightweight tag
 - Create an annotated tag
 - Push the tags to the remote repository
 
-**Additional resources**
-
-<https://git-scm.com/book/en/Git-Basics-Tagging>
-
-# Commands
-
 ```sh
 git checkout master
 
@@ -36,6 +30,10 @@ git tag
 git push origin --tags
 ```
 
+**Additional resources**
+
+<https://git-scm.com/book/en/Git-Basics-Tagging>
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues

doc/university/training/topics/unstage.md

@@ -4,8 +4,6 @@ comments: false
 
 # Unstage
 
-## Unstage
-
 - To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This will unstage the file but maintain the modifications.
 
   ```bash