debian-mirror-gitlab/doc/university/training/user_training.md

340 lines
7.7 KiB
Markdown
Raw Normal View History

2018-03-17 18:26:18 +05:30
---
comments: false
2019-09-04 21:01:54 +05:30
type: reference
2018-03-17 18:26:18 +05:30
---
2017-08-17 22:00:37 +05:30
# GitLab Git Workshop
2018-12-13 13:39:08 +05:30
## Agenda
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
1. Brief history of Git.
1. GitLab walkthrough.
1. Configure your environment.
1. Workshop.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Git introduction
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
<https://git-scm.com/about>
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- 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.
2017-08-17 22:00:37 +05:30
2019-12-04 20:38:33 +05:30
## Help
2017-08-17 22:00:37 +05:30
Use the tools at your disposal when you get stuck.
2018-12-13 13:39:08 +05:30
- Use '`git help <command>`' command.
- Use Google.
- Read documentation at <https://git-scm.com>.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## GitLab Walkthrough
2017-08-17 22:00:37 +05:30
![fit](logo.png)
2018-12-13 13:39:08 +05:30
## Configure your environment
2017-08-17 22:00:37 +05:30
- Windows: Install 'Git for Windows'
2019-12-21 20:55:43 +05:30
> <https://gitforwindows.org>
2017-08-17 22:00:37 +05:30
- Mac: Type '`git`' in the Terminal application.
> If it's not installed, it will prompt you to install it.
2018-12-13 13:39:08 +05:30
- Debian: '`sudo apt-get install git-all`' or Red Hat '`sudo yum install git-all`'
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Git Workshop
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
### Overview
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
1. Configure Git.
1. Configure SSH Key.
1. Create a project.
1. Committing.
1. Feature branching.
1. Merge requests.
1. Feedback and Collaboration.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Configure Git
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
One-time configuration of the Git client:
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
git config --global user.name "Your Name"
git config --global user.email you@example.com
```
2018-12-13 13:39:08 +05:30
## Configure SSH Key
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
ssh-keygen -t rsa -b 4096 -C "you@computer-name"
```
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
# 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
```
2018-12-13 13:39:08 +05:30
Copy your public key and add it to your GitLab profile:
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
cat ~/.ssh/id_rsa.pub
```
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
ssh-rsa AAAAB3NzaC1yc2EAAAADAQEL17Ufacg8cDhlQMS5NhV8z3GHZdhCrZbl4gz you@example.com
```
2018-12-13 13:39:08 +05:30
## Create a project
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- 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>.
2017-08-17 22:00:37 +05:30
- Create a '`development`' or '`workspace`' directory in your home directory.
2018-12-13 13:39:08 +05:30
- Clone the '`training-examples`' project.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Commands (project)
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
mkdir ~/development
cd ~/development
-or-
mkdir ~/workspace
cd ~/workspace
git clone git@gitlab.example.com:<username>/training-examples.git
cd training-examples
```
2018-12-13 13:39:08 +05:30
## Git concepts
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
### Untracked files
2017-08-17 22:00:37 +05:30
New files that Git has not been told to track previously.
2018-12-13 13:39:08 +05:30
### Working area
2017-08-17 22:00:37 +05:30
Files that have been modified but are not committed.
2018-12-13 13:39:08 +05:30
### Staging area
2017-08-17 22:00:37 +05:30
Modified files that have been marked to go in the next commit.
2018-12-13 13:39:08 +05:30
## Committing
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
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.
2019-12-21 20:55:43 +05:30
1. View the Git log.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Commands (committing)
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
# Edit `edit_this_file.rb`
git status
git diff
git add <file>
git commit -m 'My change'
git push origin master
git log
```
2018-12-13 13:39:08 +05:30
## Feature branching
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- 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.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Feature branching steps
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
1. Create a new feature branch called 'squash_some_bugs'.
2017-08-17 22:00:37 +05:30
1. Edit '`bugs.rb`' and remove all the bugs.
2018-12-13 13:39:08 +05:30
1. Commit.
1. Push.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Commands (feature branching)
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
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
```
2018-12-13 13:39:08 +05:30
## Merge requests
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- 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.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Merge requests steps
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
Create your first merge request:
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
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.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Feedback and Collaboration
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- 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.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Feedback and Collaboration resources
2017-08-17 22:00:37 +05:30
Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:
2018-12-13 13:39:08 +05:30
<https://github.com/thoughtbot/guides/tree/master/code-review>.
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
See GitLab merge requests for examples: <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests>.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Explore GitLab projects
2017-08-17 22:00:37 +05:30
![fit](logo.png)
- Dashboard
- User Preferences
- ReadMe, Changelog, License shortcuts
- Issues
- Milestones and Labels
- Manage project members
- Project settings
2018-12-13 13:39:08 +05:30
## Tags
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- 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 annotated release tag with a stable branch.
- Consider setting deployment/release tags automatically.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Tags steps
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
1. Create a lightweight tag.
1. Create an annotated tag.
1. Push the tags to the remote repository.
2017-08-17 22:00:37 +05:30
2019-12-21 20:55:43 +05:30
Additional resources: <https://git-scm.com/book/en/v2/Git-Basics-Tagging>.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Commands (tags)
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
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
```
2018-12-13 13:39:08 +05:30
## Merge conflicts
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
- Happen often.
- Learning to fix conflicts is hard.
- Practice makes perfect.
2017-08-17 22:00:37 +05:30
- Force push after fixing conflicts. Be careful!
2018-12-13 13:39:08 +05:30
## Merge conflicts steps
2017-08-17 22:00:37 +05:30
1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
2018-12-13 13:39:08 +05:30
1. Commit and push.
2017-08-17 22:00:37 +05:30
1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
2018-12-13 13:39:08 +05:30
1. Commit and push to master.
1. Create a merge request.
2017-08-17 22:00:37 +05:30
2018-12-13 13:39:08 +05:30
## Merge conflicts commands
2017-08-17 22:00:37 +05:30
After creating a merge request you should notice that conflicts exist. Resolve
the conflicts locally by rebasing.
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
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
```
2018-12-13 13:39:08 +05:30
## Rebase with squash
2017-08-17 22:00:37 +05:30
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.
2018-12-13 13:39:08 +05:30
## Rebase with squash commands
2017-08-17 22:00:37 +05:30
Squash the commits on the same branch we used for the merge conflicts step.
2020-03-13 15:44:24 +05:30
```shell
2017-08-17 22:00:37 +05:30
git rebase -i master
```
In the editor, leave the first commit as 'pick' and set others to 'fixup'.
2018-12-13 13:39:08 +05:30
## Questions?
2017-08-17 22:00:37 +05:30
![fit](logo.png)
Thank you for your hard work!
2018-12-13 13:39:08 +05:30
## Additional Resources
2017-08-17 22:00:37 +05:30
2019-09-04 21:01:54 +05:30
See [additional resources](index.md#additional-resources).
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->