Added training material
This commit is contained in:
parent
1f949c0a6b
commit
b5a46821ba
|
@ -212,5 +212,8 @@ The curriculum is composed of GitLab videos, screencasts, presentations, project
|
|||
|
||||
1. [Support Path](support/README.md)
|
||||
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. [Client Assessment of GitLab versus GitHub](https://docs.google.com/a/gitlab.com/spreadsheets/d/18cRF9Y5I6I7Z_ab6qhBEW55YpEMyU4PitZYjomVHM-M/edit?usp=sharing)
|
||||
|
|
|
@ -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)
|
Binary file not shown.
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
After Width: | Height: | Size: 43 KiB |
|
@ -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.
|
Binary file not shown.
After Width: | Height: | Size: 32 KiB |
|
@ -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)
|
|
@ -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.
|
|
@ -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
|
||||
```
|
|
@ -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>
|
||||
```
|
|
@ -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
|
||||
```
|
|
@ -0,0 +1,10 @@
|
|||
# Explore GitLab projects
|
||||
|
||||
----------
|
||||
|
||||
- Dashboard
|
||||
- User Preferences
|
||||
- Issues
|
||||
- Milestones and Labels
|
||||
- Manage project members
|
||||
- Project settings
|
|
@ -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
|
||||
```
|
|
@ -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
|
|
@ -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/
|
||||
```
|
|
@ -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
|
|
@ -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"
|
||||
```
|
|
@ -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)
|
|
@ -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/
|
|
@ -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)
|
|
@ -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)
|
||||
```
|
|
@ -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
|
||||
```
|
|
@ -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
|
||||
```
|
|
@ -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
|
||||
```
|
|
@ -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
|
||||
```
|
|
@ -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 New Issue