Enjoy privacy on GitLabMaxis Kao @ Yahoo Search

Before we jump into … ...

Let’s take a look at Version Control

Version Control

Version Control

1. What is version control?2. Why should we care?

Version Control

1. What is version control?2. Why should we care?

> What is version control?

➔ << about version control >>:

“records changes to a file or set of files over time so that you can recall specific versions later”

➔ 講中文:“能夠找回之前的版本”

> What is version control?

Version Control check list:

[ ] record changes over time [ ] recall a specific version

根據定義，可以用以下 check list 判斷是否 version control

其實聰明的大家，早就會用了！

很簡單，把版本取在檔名上

> What is version control?

Q: 這樣做有達到 version control 嗎?

A: 有！

> What is version control?

Version Control check list:

[ v ] record changes over time [ v ] recall a specific version\

既然已經是 version control

那還要用 gitlab 幹嘛?

既然已經是 version control

那還要用 gitlab 幹嘛?

人生中最重要的就是這個

But

1. What is version control?2. Why should we care?

Version Control

情境

➔ 當程式開始長大

➔ 當共同開發的人越來越多

> Why should we care?

➔ 當程式開始長大

● redundant content○ 在 v1 修了一個 bug 變為 v2，可能整份 3000 行的 code

只有一個 3 行的 if ... else 邏輯不一樣

● hard to maintain○ 很難直接從檔名中得到有用資訊： v4、v6、v8 裡面各自

有什麼 feature?

> Why should we care?

MyCrazyApp.v0.pyMyCrazyApp.v1.pyMyCrazyApp.v2.pyMyCrazyApp.v3.pyMyCrazyApp.v4.pyMyCrazyApp.v5.pyMyCrazyApp.v6.pyMyCrazyApp.v7.pyMyCrazyApp.v8.pyMyCrazyApp.v9.pyMyCrazyApp.v10.py

?

??

➔ 當共同開發的人越來越多

● hard to merge○ 小火龍休假回來，他寫的 v3 跟 皮卡丘 的 v6 要 merge，

必須試著把他自己的 change 加在 皮卡丘 的上面

● message exchange cost○ 傑尼龜 從 皮卡丘 那 fork 出 v2 想開發一個大功能，但因

為埋頭苦幹太久，中間不知道其他人到底做了什麼改動，

他的 v3 跟皮卡丘的 v3 完全不一樣

> Why should we care?

MyCrazyApp.v1.pyMyCrazyApp.v2.py

(休假去)

MyCrazyApp.v3.py

MyCrazyApp.v0.pyMyCrazyApp.v1.pyMyCrazyApp.v2.pyMyCrazyApp.v3.pyMyCrazyApp.v4.pyMyCrazyApp.v5.pyMyCrazyApp.v6.pyMyCrazyApp.v7.pyMyCrazyApp.v8.pyMyCrazyApp.v9.pyMyCrazyApp.v10.py

(還沒加入)

MyCrazyApp.v2.py

(寫很久)

MyCrazyApp.v3.py

皮卡丘 傑尼龜小火龍

Time

3 pain points of filename versioning

● hard to maintain

● redundancy

● difficult to collabortaion

Solutions

Version Control Systems (VCS)

● Common VCS

○ CVS

○ SVN

○ Git

○ Mercurial

Pros and cons?

Pros and cons

We might spend a whole day to argue with each other on this topic!

Since it’s not our focus right now, let’s move on to the next chpater :D

take-away

Git SVN

distributed centralized

Personally I prefer using Git because it is the distributed version control system with the biggest community, i.e., Github.

Then why Gitlab?

Free private repositories !

Gitlab

Singup, of course

Local

$ ssh-keygen

// keep pressing `enter`

$ cat ~/.ssh/id_rsa.pub

“ssh-rsa AAAAB3NzaC1…”

// copy the public key and paste to Gitlab

Gitlab

Setup SSH Keys (1/2)

Gitlab

navigate to “SSK Keys”

paste the public key in your computer

Add a simple title, e.g., “my macbook”

Add key

Setup SSH Keys (2/2)

> Go here to create one

> or use + on the navigation bar

Start a new project?

Work on an existing project (1/2)

> Find the existing one

> Copy the ssh link on top of the project

Work on an existing project (2/2)

Clone the entire repository

$ git clone git@gitlab.com:<your-own-project>.git

Wait, I’m new to Git

● Git 很好學，中英文資源也很多，花點時間看看吧！

○ Offical site

○ Tutorial

○ Slides

workflow

1. pull the latest version on master branch

2. check out a new branch to start working on some new feature

3. commit your change

4. push to remote branch on gitlab

5. go to Gitlab and create a Merge Request ( = Pull Request on Github)

6. request for code review

7. merge it if everything looks good

Local

Gitlab

1. pull the latest version on master branch

$ git checkout master // switch to master branch

$ git pull origin master // pull the latest change from origin/master to master

workflow (1/7)

2. check out a new branch to start working on some new feature

$ git checkout -b “new-feature” // create a new branch named “new-feature”

work on something cool …

workflow (2/7)

3. commit your change

$ git add <file(s) for the next commit> // staged file(s)

$ git commit -m “some cool feature” // commit with message

workflow (3/7)

4. push to remote branch on gitlab

$ git push origin new-feature // push local branch “new-feature” to origin/new-feature

workflow (4/7)

5. go to Gitlab and create a Merge Request ( = Pull Request on Github)

workflow (5/7)

5. go to Gitlab and create a Merge Request ( = Pull Request on Github)

workflow (5/7)

6. request for code review

7. merge it if everything looks good

workflow (6/7)

7. merge it if everything looks good

workflow (7/7)