diff options
author | Sean Packham <seanpackham@gitlab.com> | 2016-10-20 13:38:32 +0300 |
---|---|---|
committer | Sean Packham <seanpackham@gitlab.com> | 2016-10-20 13:38:32 +0300 |
commit | b5a46821ba5627ad5f4803511069b8493910382f (patch) | |
tree | 14f2bce87fb44d9a1a651e7342ae305d61d082af /doc/university/training | |
parent | 1f949c0a6b08563f3abcd9fd4c9e750c4097b44b (diff) |
Added training material
Diffstat (limited to 'doc/university/training')
26 files changed, 1380 insertions, 0 deletions
diff --git a/doc/university/training/gitlab_flow.md b/doc/university/training/gitlab_flow.md new file mode 100755 index 00000000000..a7db1f2e069 --- /dev/null +++ b/doc/university/training/gitlab_flow.md @@ -0,0 +1,53 @@ +# GitLab Flow + +- A simplified branching strategy +- All features and fixes first go to master +- Allows for 'production' or 'stable' branches +- Bug fixes/hot fix patches are cherry-picked from master + +--- + +# Feature branches + +- Create a feature/bugfix branch to do all work +- Use merge requests to merge to master + +![inline](gitlab_flow/feature_branches.png) + +--- + +# Production branch + +- One, long-running production release branch + as opposed to individual stable branches +- Consider creating a tag for each version that gets deployed + +--- + +# Production branch + +![inline](gitlab_flow/production_branch.png) + +--- + +# Release branch + +- Useful if you release software to customers +- When preparing a new release, create stable branch + from master +- Consider creating a tag for each version +- Cherry-pick critical bug fixes to stable branch for patch release +- Never commit bug fixes directly to stable branch + +--- + +# Release branch + +![inline](gitlab_flow/release_branches.png) + +--- + +# More details + +Blog post on 'GitLab Flow' at +[http://doc.gitlab.com/ee/workflow/gitlab_flow.html](http://doc.gitlab.com/ee/workflow/gitlab_flow.html) diff --git a/doc/university/training/gitlab_flow/feature_branches.png b/doc/university/training/gitlab_flow/feature_branches.png Binary files differnew file mode 100644 index 00000000000..88addb623ee --- /dev/null +++ b/doc/university/training/gitlab_flow/feature_branches.png diff --git a/doc/university/training/gitlab_flow/production_branch.png b/doc/university/training/gitlab_flow/production_branch.png Binary files differnew file mode 100644 index 00000000000..33fb26dd621 --- /dev/null +++ b/doc/university/training/gitlab_flow/production_branch.png diff --git a/doc/university/training/gitlab_flow/release_branches.png b/doc/university/training/gitlab_flow/release_branches.png Binary files differnew file mode 100644 index 00000000000..da7ae53413a --- /dev/null +++ b/doc/university/training/gitlab_flow/release_branches.png diff --git a/doc/university/training/index.md b/doc/university/training/index.md new file mode 100755 index 00000000000..03179ff5a77 --- /dev/null +++ b/doc/university/training/index.md @@ -0,0 +1,6 @@ +# GitLab Training Material + +All GitLab training material is stored in markdown format. Slides are +generated using [Deskset](http://www.decksetapp.com/). + +All training material is open to public contribution. diff --git a/doc/university/training/logo.png b/doc/university/training/logo.png Binary files differnew file mode 100644 index 00000000000..cc831790405 --- /dev/null +++ b/doc/university/training/logo.png diff --git a/doc/university/training/topics/additional_resources.md b/doc/university/training/topics/additional_resources.md new file mode 100755 index 00000000000..1ee615432aa --- /dev/null +++ b/doc/university/training/topics/additional_resources.md @@ -0,0 +1,8 @@ +## Additional Resources + +1. GitLab Documentation [http://docs.gitlab.com](http://docs.gitlab.com/) +2. GUI Clients [http://git-scm.com/downloads/guis](http://git-scm.com/downloads/guis) +3. Pro git book [http://git-scm.com/book](http://git-scm.com/book) +4. Platzi Course [https://courses.platzi.com/courses/git-gitlab/](https://courses.platzi.com/courses/git-gitlab/) +5. Code School tutorial [http://try.github.io/](http://try.github.io/) +6. Contact Us - [subscribers@gitlab.com](subscribers@gitlab.com) diff --git a/doc/university/training/topics/agile_git.md b/doc/university/training/topics/agile_git.md new file mode 100755 index 00000000000..e6e4fea9b51 --- /dev/null +++ b/doc/university/training/topics/agile_git.md @@ -0,0 +1,33 @@ +# Agile and Git + +---------- + +## Agile + +Lean software development methods focused on collaboration and interaction +with fast and smaller deployment cycles. + +---------- + +## Where Git comes in + +Git is an excellent tool for an Agile team considering that it allows +decentralized and simultaneous development. + +---------- + +### Branching And Workflows + +Branching in an Agile environment usually happens around user stories with one +or more developers working on it. + +If more than one developer then another branch for each developer is also used +with his/her initials, and US id. + +After its tested merge into master and remove the branch. + +---------- + +## What about GitLab +Tools like GitLab enhance collaboration by adding dialog around code mainly +through issues and merge requests. diff --git a/doc/university/training/topics/bisect.md b/doc/university/training/topics/bisect.md new file mode 100755 index 00000000000..a60c4365e0c --- /dev/null +++ b/doc/university/training/topics/bisect.md @@ -0,0 +1,81 @@ +# 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 + +1. Start the bisect process +2. Enter the bad revision (usually latest commit) +3. Enter a known good revision (commit/branch) +4. Run code to see if bug still exists +5. Tell bisect the result +6. Repeat the previous 2 items until you find the offending commit + +---------- + +## Setup + +``` + mkdir bisect-ex + cd bisect-ex + touch index.html + git add -A + git commit -m "starting out" + vi index.html + # Add all good + git add -A + git commit -m "second commit" + vi index.html + # Add all good 2 + git add -A + git commit -m "third commit" + vi index.html +``` + +---------- + +``` + # Add all good 3 + git add -A + git commit -m "fourth commit" + vi index.html + # This looks bad + git add -A + git commit -m "fifth commit" + vi index.html + # Really bad + git add -A + git commit -m "sixth commit" + vi index.html + # again just bad + git add -A + git commit -m "seventh commit" +``` + +---------- + +## Commands + +``` + git bisect start + # Test your code + git bisect bad + git bisect next + # Say yes to the warning + # Test + git bisect good + # Test + git bisect bad + # Test + git bisect good + # done + git bisect reset +``` diff --git a/doc/university/training/topics/cherry_picking.md b/doc/university/training/topics/cherry_picking.md new file mode 100755 index 00000000000..af7a70a2818 --- /dev/null +++ b/doc/university/training/topics/cherry_picking.md @@ -0,0 +1,39 @@ +# 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 + +1. Check out a new 'stable' branch from 'master' +1. Change back to 'master' +1. Edit '`cherry_pick.rb`' and commit the changes. +1. Check commit log to get the commit SHA +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 +git checkout master + +# Edit `cherry_pick.rb` +git add cherry_pick.rb +git commit -m 'Fix bugs in cherry_pick.rb' +git log +# Copy commit SHA +git checkout stable + +git cherry-pick <commit SHA> +``` diff --git a/doc/university/training/topics/env_setup.md b/doc/university/training/topics/env_setup.md new file mode 100755 index 00000000000..8149379b36f --- /dev/null +++ b/doc/university/training/topics/env_setup.md @@ -0,0 +1,60 @@ +# Configure your environment + +---------- +## Install + +- **Windows** + - Install 'Git for Windows' from 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** + ```bash + sudo yum install git-all + ``` + ```bash + sudo apt-get install git-all + ``` + +---------- + +## Configure Git + +One-time configuration of the Git client + +```bash +git config --global user.name "Your Name" +git config --global user.email you@example.com +``` + +---------- + +## Configure SSH Key + +```bash +ssh-keygen -t rsa -b 4096 -C "you@computer-name" +``` + +```bash +# You will be prompted for the following information. Press enter to accept the defaults. Defaults appear in parentheses. +Generating public/private rsa key pair. +Enter file in which to save the key (/Users/you/.ssh/id_rsa): +Enter passphrase (empty for no passphrase): +Enter same passphrase again: +Your identification has been saved in /Users/you/.ssh/id_rsa. +Your public key has been saved in /Users/you/.ssh/id_rsa.pub. +The key fingerprint is: +39:fc:ce:94:f4:09:13:95:64:9a:65:c1:de:05:4d:01 you@computer-name +``` + +Copy your public key and add it to your GitLab profile + +```bash +cat ~/.ssh/id_rsa.pub +``` + +```bash +ssh-rsa AAAAB3NzaC1yc2EAAAADAQEL17Ufacg8cDhlQMS5NhV8z3GHZdhCrZbl4gz you@example.com +``` diff --git a/doc/university/training/topics/explore_gitlab.md b/doc/university/training/topics/explore_gitlab.md new file mode 100755 index 00000000000..b65457728c0 --- /dev/null +++ b/doc/university/training/topics/explore_gitlab.md @@ -0,0 +1,10 @@ +# Explore GitLab projects + +---------- + +- Dashboard +- User Preferences +- Issues +- Milestones and Labels +- Manage project members +- Project settings diff --git a/doc/university/training/topics/feature_branching.md b/doc/university/training/topics/feature_branching.md new file mode 100755 index 00000000000..4b34406ea75 --- /dev/null +++ b/doc/university/training/topics/feature_branching.md @@ -0,0 +1,32 @@ +# Feature branching + +---------- + +- Efficient parallel workflow for teams +- Develop each feature in a branch +- Keeps changes isolated +- Consider a 1-to-1 link to issues +- Push branches to the server frequently + - Hint: This is a cheap backup for your work-in-progress code + +---------- + +## 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 + +---------- + +## 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 +``` diff --git a/doc/university/training/topics/getting_started.md b/doc/university/training/topics/getting_started.md new file mode 100755 index 00000000000..ec7bb2631aa --- /dev/null +++ b/doc/university/training/topics/getting_started.md @@ -0,0 +1,95 @@ +# Getting Started + +---------- + +## Instantiating Repositories + +* Create a new repository by instantiating it through +```bash +git init +``` +* Copy an existing project by cloning the repository through +```bash +git clone <url> +``` + +---------- + +## Central Repos + +* To instantiate a central repository a `--bare` flag is required. +* Bare repositories don't allow file editing or committing changes. +* Create a bare repo with +```bash +git init --bare project-name.git +``` + +---------- + +## Instantiate workflow with clone + +1. Create a project in your user namespace + - Choose to import from 'Any Repo by URL' and use + https://gitlab.com/gitlab-org/training-examples.git +2. Create a '`Workspace`' directory in your home directory. +3. Clone the '`training-examples`' project + +---------- + +## Commands + +``` +mkdir ~/workspace +cd ~/workspace + +git clone git@gitlab.example.com:<username>/training-examples.git +cd training-examples +``` +---------- + +## Git concepts + +**Untracked files** + +New files that Git has not been told to track previously. + +**Working area** + +Files that have been modified but are not committed. + +**Staging area** + +Modified files that have been marked to go in the next commit. + +---------- + +## Committing Workflow + +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 + +---------- + +## Commands + +``` +# Edit `edit_this_file.rb` +git status +git diff +git add <file> +git commit -m 'My change' +git push origin master +git log +``` + +---------- + +## Note + +* git fetch vs pull +* Pull is git fetch + git merge diff --git a/doc/university/training/topics/git_add.md b/doc/university/training/topics/git_add.md new file mode 100755 index 00000000000..9ffb4b9c859 --- /dev/null +++ b/doc/university/training/topics/git_add.md @@ -0,0 +1,33 @@ +# Git Add + +---------- + +## Git Add + +Adds content to the index or staging area. + +* Adds a list of file +```bash +git add <files> +``` +* Adds all files including deleted ones +```bash +git add -A +``` + +---------- + +## Git add continued + +* Add all text files in current dir +```bash +git add *.txt +``` +* Add all text file in the project +```bash +git add "*.txt*" +``` +* Adds all files in directory +```bash +git add views/layouts/ +``` diff --git a/doc/university/training/topics/git_intro.md b/doc/university/training/topics/git_intro.md new file mode 100755 index 00000000000..ca1ff29d93b --- /dev/null +++ b/doc/university/training/topics/git_intro.md @@ -0,0 +1,24 @@ +# Git introduction + +---------- + +## Intro + +https://git-scm.com/about + +- Distributed version control + - Does not rely on connection to a central server + - Many copies of the complete history +- Powerful branching and merging +- Adapts to nearly any workflow +- Fast, reliable and stable file format + +---------- + +## Help! + +Use the tools at your disposal when you get stuck. + +- Use '`git help <command>`' command +- Use Google +- Read documentation at https://git-scm.com diff --git a/doc/university/training/topics/git_log.md b/doc/university/training/topics/git_log.md new file mode 100755 index 00000000000..32ebceff491 --- /dev/null +++ b/doc/university/training/topics/git_log.md @@ -0,0 +1,57 @@ +# Git Log + +---------- + +Git log lists commit history. It allows searching and filtering. + +* Initiate log +``` +git log +``` + +* Retrieve set number of records: +``` +git log -n 2 +``` + +* Search commits by author. Allows user name or a regular expression. +``` +git log --author="user_name" +``` + +---------- + +* Search by comment message. +``` +git log --grep="<pattern>" +``` + +* Search by date +``` +git log --since=1.month.ago --until=3.weeks.ago +``` + + +---------- + +## Git Log Workflow + +1. Change to workspace directory +2. Clone the multi runner projects +3. Change to project dir +4. Search by author +5. Search by date +6. Combine + +---------- + +## Commands + +``` +cd ~/workspace +git clone git@gitlab.com:gitlab-org/gitlab-ci-multi-runner.git +cd gitlab-ci-multi-runner +git log --author="Travis" +git log --since=1.month.ago --until=3.weeks.ago +git log --since=1.month.ago --until=1.day.ago --author="Travis" +``` diff --git a/doc/university/training/topics/gitlab_flow.md b/doc/university/training/topics/gitlab_flow.md new file mode 100755 index 00000000000..8e5d3baf959 --- /dev/null +++ b/doc/university/training/topics/gitlab_flow.md @@ -0,0 +1,53 @@ +# GitLab Flow + +---------- + +- A simplified branching strategy +- All features and fixes first go to master +- Allows for 'production' or 'stable' branches +- Bug fixes/hot fix patches are cherry-picked from master + +---------- + +### Feature branches + +- Create a feature/bugfix branch to do all work +- Use merge requests to merge to master + +![inline](http://gitlab.com/gitlab-org/University/raw/5baea0fe222a915d0500e40747d35eb18681cdc3/training/gitlab_flow/feature_branches.png) + +---------- + +## Production branch + +- One, long-running production release branch + as opposed to individual stable branches +- Consider creating a tag for each version that gets deployed + +---------- + +## Production branch + +![inline](http://gitlab.com/gitlab-org/University/raw/5baea0fe222a915d0500e40747d35eb18681cdc3/training/gitlab_flow/production_branch.png) + +---------- + +## Release branch + +- Useful if you release software to customers +- When preparing a new release, create stable branch + from master +- Consider creating a tag for each version +- Cherry-pick critical bug fixes to stable branch for patch release +- Never commit bug fixes directly to stable branch + +---------- + +![inline](http://gitlab.com/gitlab-org/University/raw/5baea0fe222a915d0500e40747d35eb18681cdc3/training/gitlab_flow/release_branches.png) + +---------- + +## More details + +Blog post on 'GitLab Flow' at +[http://doc.gitlab.com/ee/workflow/gitlab_flow.html](http://doc.gitlab.com/ee/workflow/gitlab_flow.html) diff --git a/doc/university/training/topics/merge_conflicts.md b/doc/university/training/topics/merge_conflicts.md new file mode 100755 index 00000000000..77807b3e7ef --- /dev/null +++ b/doc/university/training/topics/merge_conflicts.md @@ -0,0 +1,70 @@ +# Merge conflicts + +---------- + +- Happen often +- Learning to fix conflicts is hard +- Practice makes perfect +- Force push after fixing conflicts. Be careful! + +---------- + +## Merge conflicts + +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 + +---------- + +## Commands + +``` +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 +``` + +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 +``` +---------- + +## Note +* 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/ diff --git a/doc/university/training/topics/merge_requests.md b/doc/university/training/topics/merge_requests.md new file mode 100755 index 00000000000..5b446f02f63 --- /dev/null +++ b/doc/university/training/topics/merge_requests.md @@ -0,0 +1,43 @@ +# 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** + +1. Use the blue button in the activity feed +1. View the diff (changes) and leave a comment +1. Push a new commit to the same branch +1. 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: +[https://github.com/thoughtbot/guides/tree/master/code-review](https://github.com/thoughtbot/guides/tree/master/code-review) + +See GitLab merge requests for examples: +[https://gitlab.com/gitlab-org/gitlab-ce/merge_requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests) diff --git a/doc/university/training/topics/rollback_commits.md b/doc/university/training/topics/rollback_commits.md new file mode 100755 index 00000000000..cf647284604 --- /dev/null +++ b/doc/university/training/topics/rollback_commits.md @@ -0,0 +1,81 @@ +# Rollback Commits + +---------- + +## 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 + + +---------- + +## Commands + +``` +# 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) +``` diff --git a/doc/university/training/topics/stash.md b/doc/university/training/topics/stash.md new file mode 100755 index 00000000000..c1bdda32645 --- /dev/null +++ b/doc/university/training/topics/stash.md @@ -0,0 +1,86 @@ +# Git Stash + +---------- + +We use git stash to store our changes when they are not ready to be committed +and we need to change to a different branch. + +* Stash +``` +git stash save +# or +git stash +# or with a message +git stash save "this is a message to display on the list" +``` + +* Apply stash to keep working on it +``` +git stash apply +# or apply a specific one from out stack +git stash apply stash@{3} +``` + +---------- + +* Every time we save a stash it gets stacked so by using list we can see all our +stashes. + +``` +git stash list +# or for more information (log methods) +git stash list --stat +``` + +* To clean our stack we need to manually remove them. + +``` +# drop top stash +git stash drop +# or +git stash drop <name> +# to clear all history we can use +git stash clear +``` + +---------- + +* Apply and drop on one command + +``` + git stash pop +``` + +* If we meet conflicts we need to either reset or commit our changes. + +* Conflicts through `pop` will not drop a stash afterwards. + +---------- + +## Git Stash + +1. Modify a file +2. Stage file +3. Stash it +4. View our stash list +5. Confirm no pending changes through status +5. Apply with pop +6. View list to confirm changes + +---------- + +## Commands + +``` +# Modify edit_this_file.rb file +git add . + +git stash save "Saving changes from edit this file" + +git stash list +git status + +git stash pop +git stash list +git status +``` diff --git a/doc/university/training/topics/subtree.md b/doc/university/training/topics/subtree.md new file mode 100755 index 00000000000..5d869af64c1 --- /dev/null +++ b/doc/university/training/topics/subtree.md @@ -0,0 +1,55 @@ +## Subtree + +---------- + +## Subtree + +* Used when there are nested repositories. +* Not recommended when the amount of dependencies is too large +* For these cases we need a dependency control system +* Command are painfully long so aliases are necessary + +---------- + +## Subtree Aliases + +* Add: git subtree add --prefix <target-folder> <url> <branch> --squash +* Pull: git subtree add --prefix <target-folder> <url> <branch> --squash +* Push: git subtree add --prefix <target-folder> <url> <branch> +* Ex: git config alias.sbp 'subtree pull --prefix st / + git@gitlab.com:balameb/subtree-nested-example.git master --squash' + +---------- + +``` + # Add an alias + # Add + git config alias.sba 'subtree add --prefix st / + git@gitlab.com:balameb/subtree-nested-example.git master --squash' + # Pull + git config alias.sbpl 'subtree pull --prefix st / + git@gitlab.com:balameb/subtree-nested-example.git master --squash' + # Push + git config alias.sbph 'subtree push --prefix st / + git@gitlab.com:balameb/subtree-nested-example.git master' + + # Adding this subtree adds a st dir with a readme + git sba + vi st/README.md + # Edit file + git status shows differences + +``` + +---------- + +``` + # Adding, or committing won't change the sub repo at remote + # even if we push + git add -A + git commit -m "Adding to subtree readme" + + # Push to subtree repo + git sbph + # now we can check our remote sub repo +``` diff --git a/doc/university/training/topics/tags.md b/doc/university/training/topics/tags.md new file mode 100755 index 00000000000..e9607b5a875 --- /dev/null +++ b/doc/university/training/topics/tags.md @@ -0,0 +1,38 @@ +# Tags + +---------- + +- Useful for marking deployments and releases +- Annotated tags are an unchangeable part of Git history +- Soft/lightweight tags can be set and removed at will +- Many projects combine an anotated release tag with a stable branch +- Consider setting deployment/release tags automatically + +---------- + +# Tags + +- Create a lightweight tag +- Create an annotated tag +- Push the tags to the remote repository + +**Additional resources** + +[http://git-scm.com/book/en/Git-Basics-Tagging](http://git-scm.com/book/en/Git-Basics-Tagging) + +---------- + +# Commands + +``` +git checkout master + +# Lightweight tag +git tag my_lightweight_tag + +# Annotated tag +git tag -a v1.0 -m ‘Version 1.0’ +git tag + +git push origin --tags +``` diff --git a/doc/university/training/topics/unstage.md b/doc/university/training/topics/unstage.md new file mode 100755 index 00000000000..17dbb64b9e6 --- /dev/null +++ b/doc/university/training/topics/unstage.md @@ -0,0 +1,31 @@ +# Unstage + +---------- + +## Unstage + +* To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch. + +```bash +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: + +```bash +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 +``` diff --git a/doc/university/training/user_training.md b/doc/university/training/user_training.md new file mode 100755 index 00000000000..35afe73708f --- /dev/null +++ b/doc/university/training/user_training.md @@ -0,0 +1,392 @@ +# GitLab Git Workshop + +--- + +# Agenda + +1. Brief history of Git +1. GitLab walkthrough +1. Configure your environment +1. Workshop + +--- + +# Git introduction + +https://git-scm.com/about + +- Distributed version control + - Does not rely on connection to a central server + - Many copies of the complete history +- Powerful branching and merging +- Adapts to nearly any workflow +- Fast, reliable and stable file format + +--- + +# Help! + +Use the tools at your disposal when you get stuck. + +- Use '`git help <command>`' command +- Use Google +- Read documentation at https://git-scm.com + +--- + +# GitLab Walkthrough + +![fit](logo.png) + +--- + +# Configure your environment + +- 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. + +- Debian: '`sudo apt-get install git-all`' +or Red Hat '`sudo yum install git-all`' + +--- + +# Git Workshop + +## Overview + +1. Configure Git +1. Configure SSH Key +1. Create a project +1. Committing +1. Feature branching +1. Merge requests +1. Feedback and Collaboration + +--- + +# Configure Git + +One-time configuration of the Git client + +```bash +git config --global user.name "Your Name" +git config --global user.email you@example.com +``` + +--- + +# Configure SSH Key + +```bash +ssh-keygen -t rsa -b 4096 -C "you@computer-name" +``` + +```bash +# You will be prompted for the following information. Press enter to accept the defaults. Defaults appear in parentheses. +Generating public/private rsa key pair. +Enter file in which to save the key (/Users/you/.ssh/id_rsa): +Enter passphrase (empty for no passphrase): +Enter same passphrase again: +Your identification has been saved in /Users/you/.ssh/id_rsa. +Your public key has been saved in /Users/you/.ssh/id_rsa.pub. +The key fingerprint is: +39:fc:ce:94:f4:09:13:95:64:9a:65:c1:de:05:4d:01 you@computer-name +``` + +Copy your public key and add it to your GitLab profile + +```bash +cat ~/.ssh/id_rsa.pub +``` + +```bash +ssh-rsa AAAAB3NzaC1yc2EAAAADAQEL17Ufacg8cDhlQMS5NhV8z3GHZdhCrZbl4gz you@example.com +``` + +--- + +# Create a project + +- Create a project in your user namespace + - Choose to import from 'Any Repo by URL' and use + https://gitlab.com/gitlab-org/training-examples.git +- Create a '`development`' or '`workspace`' directory in your home directory. +- Clone the '`training-examples`' project + +--- + +# Commands + +``` +mkdir ~/development +cd ~/development + +-or- + +mkdir ~/workspace +cd ~/workspace + +git clone git@gitlab.example.com:<username>/training-examples.git +cd training-examples +``` + +--- + +# Git concepts + +**Untracked files** + +New files that Git has not been told to track previously. + +**Working area** + +Files that have been modified but are not committed. + +**Staging area** + +Modified files that have been marked to go in the next commit. + +--- + +# Committing + +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 + +--- + +# Commands + +``` +# 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 + +- Efficient parallel workflow for teams +- Develop each feature in a branch +- Keeps changes isolated +- Consider a 1-to-1 link to issues +- Push branches to the server frequently + - Hint: This is a cheap backup for your work-in-progress code + +--- + +# 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 + +--- + +# 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 +``` + +--- + +# 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** + +1. Use the blue button in the activity feed +1. View the diff (changes) and leave a comment +1. Push a new commit to the same branch +1. 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: +[https://github.com/thoughtbot/guides/tree/master/code-review](https://github.com/thoughtbot/guides/tree/master/code-review) + +See GitLab merge requests for examples: +[https://gitlab.com/gitlab-org/gitlab-ce/merge_requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests) + +--- + +# Explore GitLab projects + +![fit](logo.png) + +- Dashboard +- User Preferences +- ReadMe, Changelog, License shortcuts +- Issues +- Milestones and Labels +- Manage project members +- Project settings + +--- + +# Tags + +- Useful for marking deployments and releases +- Annotated tags are an unchangeable part of Git history +- Soft/lightweight tags can be set and removed at will +- Many projects combine an anotated release tag with a stable branch +- Consider setting deployment/release tags automatically + +--- + +# Tags + +- Create a lightweight tag +- Create an annotated tag +- Push the tags to the remote repository + +**Additional resources** + +[http://git-scm.com/book/en/Git-Basics-Tagging](http://git-scm.com/book/en/Git-Basics-Tagging) + +--- + +# Commands + +``` +git checkout master + +# Lightweight tag +git tag my_lightweight_tag + +# Annotated tag +git tag -a v1.0 -m ‘Version 1.0’ +git tag + +git push origin --tags +``` + +--- + +# Merge conflicts + +- Happen often +- Learning to fix conflicts is hard +- Practice makes perfect +- Force push after fixing conflicts. Be careful! + +--- + +# Merge conflicts + +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 + +--- + +# Merge conflicts + +After creating a merge request you should notice that conflicts exist. Resolve +the conflicts locally by rebasing. + +``` +git rebase master + +# Fix conflicts by editing the files. + +git add conflicts.rb +git commit -m 'Fix conflicts' +git rebase --continue +git push origin <branch> -f +``` + +--- + +# Rebase with squash + +You may end up with a commit log that looks like this: + +``` +Fix issue #13 +Test +Fix +Fix again +Test +Test again +Does this work? +``` + +Squash these in to meaningful commits using an interactive rebase. + +--- + +# Rebase with squash + +Squash the commits on the same branch we used for the merge conflicts step. + +``` +git rebase -i master +``` + +In the editor, leave the first commit as 'pick' and set others to 'fixup'. + +--- + +# Questions? + +![fit](logo.png) + +Thank you for your hard work! + +**Additional Resources** + +GitLab Documentation [http://docs.gitlab.com](http://docs.gitlab.com/) +GUI Clients [http://git-scm.com/downloads/guis](http://git-scm.com/downloads/guis) +Pro git book [http://git-scm.com/book](http://git-scm.com/book) +Platzi Course [https://courses.platzi.com/courses/git-gitlab/](https://courses.platzi.com/courses/git-gitlab/) +Code School tutorial [http://try.github.io/](http://try.github.io/) +Contact Us - [subscribers@gitlab.com](subscribers@gitlab.com) |