Added training material
This commit is contained in:
parent
1f949c0a6b
commit
b5a46821ba
27 changed files with 1383 additions and 0 deletions
|
@ -212,5 +212,8 @@ The curriculum is composed of GitLab videos, screencasts, presentations, project
|
||||||
|
|
||||||
1. [Support Path](support/README.md)
|
1. [Support Path](support/README.md)
|
||||||
1. [Sales Path (redirect to sales handbook)](https://about.gitlab.com/handbook/sales-onboarding/)
|
1. [Sales Path (redirect to sales handbook)](https://about.gitlab.com/handbook/sales-onboarding/)
|
||||||
|
1. [User Training](training/user_training.md)
|
||||||
|
1. [GitLab Flow Training](training/gitlab_flow.md)
|
||||||
|
1. [Training Topics](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/university/training/topics/)
|
||||||
1. [GitLab architecture for noobs](https://dev.gitlab.org/gitlab/gitlabhq/blob/master/doc/development/architecture.md)
|
1. [GitLab architecture for noobs](https://dev.gitlab.org/gitlab/gitlabhq/blob/master/doc/development/architecture.md)
|
||||||
1. [Client Assessment of GitLab versus GitHub](https://docs.google.com/a/gitlab.com/spreadsheets/d/18cRF9Y5I6I7Z_ab6qhBEW55YpEMyU4PitZYjomVHM-M/edit?usp=sharing)
|
1. [Client Assessment of GitLab versus GitHub](https://docs.google.com/a/gitlab.com/spreadsheets/d/18cRF9Y5I6I7Z_ab6qhBEW55YpEMyU4PitZYjomVHM-M/edit?usp=sharing)
|
||||||
|
|
53
doc/university/training/gitlab_flow.md
Executable file
53
doc/university/training/gitlab_flow.md
Executable file
|
@ -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)
|
BIN
doc/university/training/gitlab_flow/feature_branches.png
Normal file
BIN
doc/university/training/gitlab_flow/feature_branches.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 20 KiB |
BIN
doc/university/training/gitlab_flow/production_branch.png
Normal file
BIN
doc/university/training/gitlab_flow/production_branch.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 21 KiB |
BIN
doc/university/training/gitlab_flow/release_branches.png
Normal file
BIN
doc/university/training/gitlab_flow/release_branches.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 43 KiB |
6
doc/university/training/index.md
Executable file
6
doc/university/training/index.md
Executable file
|
@ -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.
|
BIN
doc/university/training/logo.png
Normal file
BIN
doc/university/training/logo.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 32 KiB |
8
doc/university/training/topics/additional_resources.md
Executable file
8
doc/university/training/topics/additional_resources.md
Executable file
|
@ -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)
|
33
doc/university/training/topics/agile_git.md
Executable file
33
doc/university/training/topics/agile_git.md
Executable file
|
@ -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.
|
81
doc/university/training/topics/bisect.md
Executable file
81
doc/university/training/topics/bisect.md
Executable file
|
@ -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
|
||||||
|
```
|
39
doc/university/training/topics/cherry_picking.md
Executable file
39
doc/university/training/topics/cherry_picking.md
Executable file
|
@ -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>
|
||||||
|
```
|
60
doc/university/training/topics/env_setup.md
Executable file
60
doc/university/training/topics/env_setup.md
Executable file
|
@ -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
|
||||||
|
```
|
10
doc/university/training/topics/explore_gitlab.md
Executable file
10
doc/university/training/topics/explore_gitlab.md
Executable file
|
@ -0,0 +1,10 @@
|
||||||
|
# Explore GitLab projects
|
||||||
|
|
||||||
|
----------
|
||||||
|
|
||||||
|
- Dashboard
|
||||||
|
- User Preferences
|
||||||
|
- Issues
|
||||||
|
- Milestones and Labels
|
||||||
|
- Manage project members
|
||||||
|
- Project settings
|
32
doc/university/training/topics/feature_branching.md
Executable file
32
doc/university/training/topics/feature_branching.md
Executable file
|
@ -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
|
||||||
|
```
|
95
doc/university/training/topics/getting_started.md
Executable file
95
doc/university/training/topics/getting_started.md
Executable file
|
@ -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
|
33
doc/university/training/topics/git_add.md
Executable file
33
doc/university/training/topics/git_add.md
Executable file
|
@ -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/
|
||||||
|
```
|
24
doc/university/training/topics/git_intro.md
Executable file
24
doc/university/training/topics/git_intro.md
Executable file
|
@ -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
|
57
doc/university/training/topics/git_log.md
Executable file
57
doc/university/training/topics/git_log.md
Executable file
|
@ -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"
|
||||||
|
```
|
53
doc/university/training/topics/gitlab_flow.md
Executable file
53
doc/university/training/topics/gitlab_flow.md
Executable file
|
@ -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)
|
70
doc/university/training/topics/merge_conflicts.md
Executable file
70
doc/university/training/topics/merge_conflicts.md
Executable file
|
@ -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/
|
43
doc/university/training/topics/merge_requests.md
Executable file
43
doc/university/training/topics/merge_requests.md
Executable file
|
@ -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)
|
81
doc/university/training/topics/rollback_commits.md
Executable file
81
doc/university/training/topics/rollback_commits.md
Executable file
|
@ -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)
|
||||||
|
```
|
86
doc/university/training/topics/stash.md
Executable file
86
doc/university/training/topics/stash.md
Executable file
|
@ -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
|
||||||
|
```
|
55
doc/university/training/topics/subtree.md
Executable file
55
doc/university/training/topics/subtree.md
Executable file
|
@ -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
|
||||||
|
```
|
38
doc/university/training/topics/tags.md
Executable file
38
doc/university/training/topics/tags.md
Executable file
|
@ -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
|
||||||
|
```
|
31
doc/university/training/topics/unstage.md
Executable file
31
doc/university/training/topics/unstage.md
Executable file
|
@ -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
|
||||||
|
```
|
392
doc/university/training/user_training.md
Executable file
392
doc/university/training/user_training.md
Executable file
|
@ -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)
|
Loading…
Reference in a new issue