Commit f4632f3a authored by Marcel Amirault's avatar Marcel Amirault Committed by Marcia Ramos

Adjust headers in /university

parent a979743e
......@@ -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
......
......@@ -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.
......
......@@ -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)
......
......@@ -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
......
......@@ -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`
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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)
......
......@@ -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 .
......
......@@ -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
......
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment