user_training.md 7.48 KB
Newer Older
1 2 3 4
---
comments: false
---

Sean Packham's avatar
Sean Packham committed
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281
# 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
Pascal Borreli's avatar
Pascal Borreli committed
282
- Many projects combine an annotated release tag with a stable branch
Sean Packham's avatar
Sean Packham committed
283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395
- 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/)
396
Contact Us at `subscribers@gitlab.com`