diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-08-11 18:10:08 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-08-11 18:10:08 +0300 |
commit | 9dde2726710184f066387d044fce4ae2b3684210 (patch) | |
tree | 141da0dfc25da6b1724329a3d5cf2d51c7d45937 /doc/university/training | |
parent | 03b5d94c2c145491bd493837ec50a36e5d1d2612 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/university/training')
-rw-r--r-- | doc/university/training/end-user/README.md | 369 |
1 files changed, 2 insertions, 367 deletions
diff --git a/doc/university/training/end-user/README.md b/doc/university/training/end-user/README.md index 8d25b865855..c0251229916 100644 --- a/doc/university/training/end-user/README.md +++ b/doc/university/training/end-user/README.md @@ -1,370 +1,5 @@ --- -comments: false +redirect_to: 'https://docs.gitlab.com' --- -# Training - -This training material is the Markdown used to generate training slides -which can be found at [End User Slides](https://gitlab-org.gitlab.io/end-user-training-slides/#/) -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 -- Maintains history of changes -- 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 - 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 - -### 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 - -### 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> - -## Git Setup - -Workshop Time! - -### Setup - -- Windows: Install 'Git for Windows' - - <https://gitforwindows.org> -- 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` - -### Configure - -- One-time configuration of the Git client: - -```shell -git config --global user.name "Your Name" -git config --global user.email you@example.com -``` - -- If you don't use the global flag you can set up a different author for - each project -- Check settings with: - -```shell -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 - -```shell -mkdir ~/development -cd ~/development - --or- - -mkdir ~/workspace -cd ~/workspace -``` - -## Git Basics - -### 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 - -### 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 <https://gitlab.com> - -### New Project - -- Sign in into your <https://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 - -### Git and GitLab basics - -1. Edit `edit_this_file.rb` in `training-examples` -1. See it listed as a changed file (working area) -1. View the differences -1. Stage the file -1. Commit -1. Push the commit to the remote -1. View the Git log - -```shell -# Edit `edit_this_file.rb` -git status -git diff -git add <file> -git commit -m 'My change' -git push origin master -git log -``` - -### Feature Branching - -1. Create a new feature branch called `squash_some_bugs` -1. Edit `bugs.rb` and remove all the bugs. -1. Commit -1. Push - -```shell -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 -``` - -## Merge Request - -- 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 `Draft:` 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 request example - -- 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 - ---- - -- 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-foss/-/merge_requests) - -## 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'. -1. Commit and push -1. Checkout master and edit conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'. -1. Commit and push to master -1. Create a merge request and watch it fail -1. Rebase our new branch with master -1. Fix conflicts on the conflicts.rb file. -1. Stage the file and continue rebasing -1. Force push the changes -1. Finally continue with the Merge Request - -### Example 1/2 - -```shell -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. - -```shell -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> - -## Revert and Unstage - -### Unstage - -To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch: - -```shell -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: - -```shell -git checkout -- <file> -``` - -To remove a file from disk and repo use `git rm` and to remove a directory use the `-r` flag: - -```shell -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`: - -```shell -git rm <filename> --cache -``` - -### Undo Commits - -Undo last commit putting everything back into the staging area: - -```shell -git reset --soft HEAD^ -``` - -Add files and change message with: - -```shell -git commit --amend -m "New Message" -``` - -Undo last and remove changes - -```shell -git reset --hard HEAD^ -``` - -Same as last one but for two commits back: - -```shell -git reset --hard HEAD^^ -``` - -Don't reset after pushing - -### Reset Workflow - -1. Edit file again 'edit_this_file.rb' -1. Check status -1. Add and commit with wrong message -1. Check log -1. Amend commit -1. Check log -1. Soft reset -1. Check log -1. Pull for updates -1. Push changes - -```shell -# 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 -``` - -### `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 - -```shell -# 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 +Visit our [documentation page](https://docs.gitlab.com) for information about GitLab. |