Adds intro and content syllabus

content/feature_branching.md

-## Feature branching
-
-1. Create a new feature branch called 'squash_some_bugs'
-2. Edit 'bugs.rb' and remove all the bugs.
-3. Commit
-4. Push
-5. Commands
-
-----------
-```
-git checkout -b squash_some_bugs
-# Edit `bugs.rb`
-git status
-git add bugs.rb
-git commit -m 'Fix some buggy code'
-git push origin squash_some_bugs
-```

content/git_intro.md

-## What is a Version Control System (VCS)
-- Records changes to a file
-- Maintains history of changes
-- Disaster Recovery
-- Types of VCS: Local, Centralized and Distributed
+## Concepts
+- *Continouos Integration*: software development practice where code is integrated regularly. 
+- Integration usually includes building and testing  
+- *Continouos Deployment*: closely related to CI but also implies releasing integrated code into production
+- References: 
+  - [Martin Fowler](http://www.martinfowler.com/articles/continuousIntegration.html)
+  - [ThoughtWorks](https://www.thoughtworks.com/continuous-integration)
+  - [Agile Alliance](https://www.agilealliance.org/glossary/continuous-integration/) 

content/git_workflow.md

-## Git Workflow
-
-- Untracked files
-    - New files that Git has not been told to track previously.
-- Working area (Workspace)
-    - Files that have been modified but are not committed.
-- Staging area (Index)
-    - Modified files that have been marked to go in the next commit.
-- Upstream
-    - Hosted repository on a shared server

content/gitlab_git.md

-## Git and GitLab basics
-
-1. Edit 'edit_this_file.rb' in 'training-examples'
-2. See it listed as a changed file (working area)
-3. View the differences
-4. Stage the file
-5. Commit
-6. Push the commit to the remote
-7. View the git log
-
-----------
-
-```
-# Edit `edit_this_file.rb`
-git status
-git diff
-git add <file>
-git commit -m 'My change'
-git push origin master
-git log
-```

content/gitlab_intro.md

-## GitLab
-
-- GitLab is an application to code, test and deploy.
-- Provides repository management with access controls, code reviews,
-  issue tracking, Merge Requests, and other features.
-- The hosted version of GitLab is gitlab.com
-
-----------
-
-## New Project
-- Sign in into your gitlab.com account
-- Create a project
-- 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

content/help.md

-## Getting Help
-
-- Use the tools at your disposal when you get stuck.
-  - Use 'git help <command>' command
-  - Use Google (i.e. StackOverflow, Google groups)
-  - Read documentation at https://git-scm.com

content/install.md

-## Install
-
-- Windows: Install 'Git for Windows'
-  - https://git-for-windows.github.io
-- Mac: Type 'git' in the Terminal application.
-  - If it's not installed, it will prompt you to install it.
-- Linux
-  - Debian: 'sudo apt-get install git-all'
-  - Red Hat 'sudo yum install git-all'

content/merge_conflicts.md

-## 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'.
-2. Commit and push
-3. Checkout master and edit conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'.
-4. Commit and push to master
-5. Create a merge request and watch it fail
-6. Rebase our new branch with master
-7. Fix conflicts on the conflicts.rb file.
-8. Stage the file and continue rebasing
-9. Force push the changes
-10. Finally continue with the Merge Request
-
-----------
-
-## Example 1/2
-
-```
-git checkout -b conflicts_branch
-
-# vi conflicts.rb
-# Add 'Line4' and 'Line5'
-
-git commit -am "add line4 and line5"
-git push origin conflicts_branch
-
-git checkout 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.
-
-git add conflicts.rb
-# No need to commit this file
-
-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
-
-- When to use 'git merge' and when to use 'git rebase'
-- Rebase when updating your branch with master
-- Merge when bringing changes from feature to master
-- Reference: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

content/merge_requests.md

-## 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
-- Add 'WIP' to the title if it's a work in progress
-- When accepting, always delete the branch
-- Anyone can comment, not just the assignee
-- Push corrections to the same branch
-
-
-----------
-
-## Merge requests
-
-- Create your first merge request
-  - Use the blue button in the activity feed
-  - View the diff (changes) and leave a comment
-  - 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
-- Giving feedback is hard
-- Be as kind as possible
-- Receiving feedback is hard
-- Be as receptive as possible
-- Feedback is about the best code, not the person. You are not your code
-- Feedback and Collaboration
-
-----------
-
-## 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
-See GitLab merge requests for examples: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests

content/revert.md

-## Undo Commits
-
-- Undo last commit putting everything back into the staging area.
-  ```
-  git reset --soft HEAD^
-  ```
-- Add files and change message with:
-  ```
-  git commit --amend -m "New Message"
-  ```
-- Undo last and remove changes
-  ```
-  git reset --hard HEAD^
-  ```
-- Same as last one but for two commits back
-  ```
-  git reset --hard HEAD^^
-  ```
-**Don't reset after pushing**
-
-----------
-
-## Reset Workflow
-
-1. Edit file again 'edit_this_file.rb'
-2. Check status
-3. Add and commit with wrong message
-4. Check log
-5. Amend commit
-6. Check log
-7. Soft reset
-8. Check log
-9. Pull for updates
-10. 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
-```
-
-----------
-
-## Note
-
-- 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)
-```

content/short_story_git.md

-## Short Story of Git
-
-- 1991-2002: The Linux kernel was being maintained by sharing archived files
-  and patches.
-- 2002: The Linux kernel project began using a DVCS called BitKeeper
-- 2005: BitKeeper revoked the free-of-charge status and Git was created

content/unstage.md

-## Unstage
-
-- To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch.
-
-  ```
-  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>
-  ```
-----------
-
-- 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>
-  ```
-
-- 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
-  ```

content/what_git.md

-## What is Git
-
-- Distributed Version Control System
-- Great branching model that adapts well to most workflows
-- Fast and reliable
-- Keeps a complete history
-- Disaster recovery friendly
-- Open Source

index.html

@@ -45,7 +45,7 @@
 				<!-- View presentation notes -->
 				<section data-markdown>
-					# GitLab
+					# GitLab CI/CD
 					Training
 				</section>
@@ -57,31 +57,17 @@
 					<table>
 						<thead>
 							<tr>
-								<th>Section</th>
+								<th>Sections</th>
 							</tr>
 						</thead>
 						<tbody>
 							<tr>
-								<td>Intro</td>
+								<td>Introduction</td>
 							</tr>
 							<tr>
-								<td>Git Introduction</td>
-							</tr>
-							<tr>
-								<td>Git Setup</td>
-							</tr>
-							<tr>
-								<td>Git Workflow</td>
-							</tr>
-							<tr>
-								<td>GitLab</td>
-							</tr>
-							<tr>
-								<td>Break (10 min)</td>
-							</tr>
-							<tr>
-								<td>GitLab Workflow</td>
+								<td>Concepts</td>
 							</tr>
+
 							<tr>
 								<td>Questions</td>
 							</tr>
@@ -92,7 +78,7 @@
 			</section>
 			<section data-markdown>
-				# Git Introduction
+				# Introduction
 			</section>
 			<section data-markdown="content/git_intro.md"
@@ -103,16 +89,9 @@
 			</section>
 			<aside class="notes" data-markdown>
-				 ### 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
-    	</aside>
+				### CI/CD
+				sds
+    		</aside>
 			<section data-markdown="content/short_story_git.md"
 			 data-separator="^\n\n\n"