Skip to content

G
gitlab-ce
Commit b5a46821 authored by Sean Packham's avatar Sean Packham
Browse files
Options

Added training material

parent 1f949c0a
Show whitespace changes
Inline Side-by-side
Showing with 1383 additions and 0 deletions
doc/university/README.md
View file @ b5a46821
...@@ -212,5 +212,8 @@ The curriculum is composed of GitLab videos, screencasts, presentations, project ...@@ -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)
doc/university/training/gitlab_flow.md 0 → 100755
View file @ b5a46821
# 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)
doc/university/training/index.md 0 → 100755
View file @ b5a46821
# 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.
doc/university/training/topics/additional_resources.md 0 → 100755
View file @ b5a46821
## 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)
doc/university/training/topics/agile_git.md 0 → 100755
View file @ b5a46821
# 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.
doc/university/training/topics/bisect.md 0 → 100755
View file @ b5a46821
# 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
```
doc/university/training/topics/cherry_picking.md 0 → 100755
View file @ b5a46821
# 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>
```
doc/university/training/topics/env_setup.md 0 → 100755
View file @ b5a46821
# 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
```
doc/university/training/topics/explore_gitlab.md 0 → 100755
View file @ b5a46821
# Explore GitLab projects
----------
- Dashboard
- User Preferences
- Issues
- Milestones and Labels
- Manage project members
- Project settings
doc/university/training/topics/feature_branching.md 0 → 100755
View file @ b5a46821
# 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
```
doc/university/training/topics/getting_started.md 0 → 100755
View file @ b5a46821
# 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
doc/university/training/topics/git_add.md 0 → 100755
View file @ b5a46821
# 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/
```
doc/university/training/topics/git_intro.md 0 → 100755
View file @ b5a46821
# 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
doc/university/training/topics/git_log.md 0 → 100755
View file @ b5a46821
# 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"
```
doc/university/training/topics/gitlab_flow.md 0 → 100755
View file @ b5a46821
# 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)
doc/university/training/topics/merge_conflicts.md 0 → 100755
View file @ b5a46821
# 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/
doc/university/training/topics/merge_requests.md 0 → 100755
View file @ b5a46821
# 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)
doc/university/training/topics/rollback_commits.md 0 → 100755
View file @ b5a46821
# 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)
```
doc/university/training/topics/stash.md 0 → 100755
View file @ b5a46821
# 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
```
doc/university/training/topics/subtree.md 0 → 100755
View file @ b5a46821
## 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
```
doc/university/training/topics/tags.md 0 → 100755
View file @ b5a46821
# 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
```
doc/university/training/topics/unstage.md 0 → 100755
View file @ b5a46821
# 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
```
doc/university/training/user_training.md 0 → 100755
View file @ b5a46821
# 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)
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7