root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Adjust headers in /university

This commit is contained in:
Marcel Amirault 2019-08-16 12:07:42 +00:00 committed by Marcia Ramos
parent a979743e2b
commit f4632f3a04
12 changed files with 18 additions and 121 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/topics/autodevops/index.md
View File

@ -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

81
doc/university/training/end-user/README.md
View File

@ -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
doc/university/training/topics/bisect.md
View File

@ -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)

6
doc/university/training/topics/cherry_picking.md
View File

@ -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

4
doc/university/training/topics/feature_branching.md
View File

@ -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`

4
doc/university/training/topics/getting_started.md
View File

@ -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
doc/university/training/topics/git_add.md
View File

@ -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

4
doc/university/training/topics/merge_conflicts.md
View File

@ -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

2
doc/university/training/topics/merge_requests.md
View File

@ -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)

6
doc/university/training/topics/stash.md
View File

@ -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 .

12
doc/university/training/topics/tags.md
View File

@ -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

2
doc/university/training/topics/unstage.md
View File

@ -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