Merge branch 'master' of gitlab_gitlab:gitlab-org/gitlab-cerunner-metrics-extractor

1 files changed, 88 insertions, 143 deletions

diff --git a/doc/university/training/end-user/README.md b/doc/university/training/end-user/README.md
index 99fb5e83387..1218465c87a 100644
--- a/doc/university/training/end-user/README.md
+++ b/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,12 +41,9 @@ project.
   - Use Google (i.e. StackOverflow, Google groups)
   - Read documentation at <https://git-scm.com>
 
----
-
 ## Git Setup
-Workshop Time!
 
----
+Workshop Time!
 
 ### Setup
 
@@ -68,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:
@@ -88,9 +73,7 @@ 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)
-
----
+  - Instructions: [SSH](http://doc.gitlab.com/ce/ssh/README.html)
 
 ### Workspace
 
@@ -98,8 +81,6 @@ git config --global --list
 - Create a workspace or development directory
 - This is where we'll be working and adding content
 
----
-
 ```bash
 mkdir ~/development
 cd ~/development
@@ -110,24 +91,18 @@ mkdir ~/workspace
 cd ~/workspace
 ```
 
----
-
 ## Git Basics
 
----
-
 ### Git Workflow
 
 - Untracked files
-    - New files that Git has not been told to track previously.
+  - New files that Git has not been told to track previously.
 - Working area (Workspace)
-    - Files that have been modified but are not committed.
+  - Files that have been modified but are not committed.
 - Staging area (Index)
-    - Modified files that have been marked to go in the next commit.
+  - Modified files that have been marked to go in the next commit.
 - Upstream
-    - Hosted repository on a shared server
-
----
+  - Hosted repository on a shared server
 
 ### GitLab
 
@@ -136,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
@@ -145,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`
@@ -157,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
@@ -169,8 +138,6 @@ git push origin master
 git log
 ```
 
----
-
 ### Feature Branching
 
 1. Create a new feature branch called `squash_some_bugs`
@@ -178,8 +145,6 @@ git log
 1. Commit
 1. Push
 
----
-
 ```shell
 git checkout -b squash_some_bugs
 # Edit `bugs.rb`
@@ -189,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
@@ -205,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
@@ -215,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
@@ -229,26 +184,17 @@ git push origin squash_some_bugs
 
 ---
 
-### Feedback and Collaboration
-
-- 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'.
@@ -262,47 +208,45 @@ git push origin squash_some_bugs
 1. Force push the changes
 1. Finally continue with the Merge Request
 
----
-
 ### Example 1/2
 
-    git checkout -b conflicts_branch
+```sh
+git checkout -b conflicts_branch
 
-    # vi conflicts.rb
-    # Add 'Line4' and 'Line5'
+# vi conflicts.rb
+# Add 'Line4' and 'Line5'
 
-    git commit -am "add line4 and line5"
-    git push origin conflicts_branch
+git commit -am "add line4 and line5"
+git push origin conflicts_branch
 
-    git checkout master
+git checkout master
 
-    # vi conflicts.rb
-    # Add 'Line6' and 'Line7'
-    git commit -am "add line6 and line7"
-    git push origin master
-
----
+# vi conflicts.rb
+# Add 'Line6' and 'Line7'
+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.
 
-    git checkout conflicts_branch
-    git fetch
-    git rebase master
-
-    # Fix conflicts by editing the files.
+```sh
+git checkout conflicts_branch
+git fetch
+git rebase master
 
-    git add conflicts.rb
-    # No need to commit this file
+# Fix conflicts by editing the files.
 
-    git rebase --continue
+git add conflicts.rb
+# No need to commit this file
 
-    # Remember that we have rewritten our commit history so we
-    # need to force push so that our remote branch is restructured
-    git push origin conflicts_branch -f
+git rebase --continue
 
----
+# Remember that we have rewritten our commit history so we
+# need to force push so that our remote branch is restructured
+git push origin conflicts_branch -f
+```
 
 ### Notes
 
@@ -311,55 +255,63 @@ Create a merge request on the GitLab web UI. You'll see a conflict warning.
 - 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:
 
-    git reset HEAD <file>
+```sh
+git reset HEAD <file>
+```
 
 This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use:
 
-    git checkout -- <file>
+```sh
+git checkout -- <file>
+```
 
 To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag:
 
-    git rm '*.txt'
-    git rm -r <dirname>
+```sh
+git rm '*.txt'
+git rm -r <dirname>
+```
 
 If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our .gitignore file then use `--cache`:
 
-    git rm <filename> --cache
-
----
+```sh
+git rm <filename> --cache
+```
 
 ### Undo Commits
 
 Undo last commit putting everything back into the staging area:
 
-    git reset --soft HEAD^
+```sh
+git reset --soft HEAD^
+```
 
 Add files and change message with:
 
-    git commit --amend -m "New Message"
+```sh
+git commit --amend -m "New Message"
+```
 
 Undo last and remove changes
 
-    git reset --hard HEAD^
+```sh
+git reset --hard HEAD^
+```
 
 Same as last one but for two commits back:
 
-    git reset --hard HEAD^^
+```sh
+git reset --hard HEAD^^
+```
 
 Don't reset after pushing
 
----
-
 ### Reset Workflow
 
 1. Edit file again 'edit_this_file.rb'
@@ -373,53 +325,46 @@ Don't reset after pushing
 1. Pull for updates
 1. Push changes
 
-----
-
-    # Change file edit_this_file.rb
-    git status
-    git commit -am "kjkfjkg"
-    git log
-    git commit --amend -m "New comment added"
-    git log
-    git reset --soft HEAD^
-    git log
-    git pull origin master
-    git push origin master
-
----
+```sh
+# Change file edit_this_file.rb
+git status
+git commit -am "kjkfjkg"
+git log
+git commit --amend -m "New comment added"
+git log
+git reset --soft HEAD^
+git log
+git pull origin master
+git push origin master
+```
 
-### Note
+### git revert vs git reset
 
-git revert vs git reset
 Reset removes the commit while revert removes the changes but leaves the commit
 Revert is safer considering we can revert a revert
 
-    # Changed file
-    git commit -am "bug introduced"
-    git revert HEAD
-    # New commit created reverting changes
-    # Now we want to re apply the reverted commit
-    git log # take hash from the revert commit
-    git revert <rev commit hash>
-    # reverted commit is back (new commit created again)
-
----
+```sh
+# Changed file
+git commit -am "bug introduced"
+git revert HEAD
+# New commit created reverting changes
+# Now we want to re apply the reverted commit
+git log # take hash from the revert commit
+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.
- - Centralized VCS such as Subversion includes collaboration but
-   still is prone to data loss as the main server is the single point of
-   failure.
- - Distributed VCS enables the team to have a complete copy of the project
-   and work with little dependency to the main server. In case of a main
-   server failing the project can be recovered by any of the latest copies
-   from the team
+- Local VCS was used with a filesystem or a simple db.
+- Centralized VCS such as Subversion includes collaboration but
+  still is prone to data loss as the main server is the single point of
+  failure.
+- Distributed VCS enables the team to have a complete copy of the project
+  and work with little dependency to the main server. In case of a main
+  server failing the project can be recovered by any of the latest copies
+  from the team