---
title: Git - Workflows
tags: #intern #training
description: View the slide with "Slide Mode".
---
# Git - Workflows!
---
## 1. Git
## 2. Workflows
We have a collaborative session
please prepare laptop to join!
---
## 1. Git
---
### 1.1 Mở đầu
- Đã bao giờ bạn vô tình làm các dòng code rối tung lên hay vô tình xóa các file đi và chương trình gặp lỗi.
- Vậy làm sao để hoàn nguyên code về trạng thái cũ, chẳng nhẽ lúc nào cũng tạo bản backup, 10 lần backup là 10 bản.
---
### 1.2 Hệ Thống Quản Lý phiên bản
| Version Control System - ***VCS*** | Distributed Version Control System – ***DVCS*** |
| ------------------------------------------------------------- | ------------------------------------------------------------- |
| Các files được thay đổi | Một tập hợp các snapshot |
| Thông tin được lưu trữ là một tập hợp các files | Tạo 1 snapshot, tạo tham chiếu tới snapshot |
| Thay đổi được thực hiện theo thời gian | Không có thay đổi thì tạo một tham chiếu tới snapshot trước đó|
---
| VCS | DVCS |
| ------------------------------------------ | ------------------------------------------ |
|  |  |
---
| VCS | DVCS |
| ------------------------------------------ | ------------------------------------------ |
|  |  |
---
### 1.3 Branching and Merging
- `Repository` (repo): chứa toàn bộ dự án bao gồm mã nguồn và lịch sử và nội dung thay đổi của từng file

---
### 1.3 Branching and Merging
- `Branch`: là nhánh của `Repository`
+ Các nhánh sẽ độc lập với nhau
+ Khi các nhánh hợp nhất lại với nhau thì gọi là `merge`
+ Branch ở trên local gọi là local branch, remote gọi là remote branch
+ Một branch trên local có thể liên kết với 0, 1 hoặc nhiều branch trên remote
---
### 1.3 Branching and Merging
- `Branch`: là nhánh của `Repository`

---
### 1.3 Branching and Merging
- Cấu trúc nhánh của dự án
- **Master**
- Nhánh deploy production
- Khi có hot-fix, tách ra nhánh `hot-fix` để xử lý, sau đó merge `fast-forward` vào nhánh `master`.
- **Dev**
- Tách ra từ `master`
- Fast-forward về `master` ở cuối mỗi sprint
- **Features**
- Tách ra từ `dev` để làm tính năng mới
- Có thể có 1 hoặc nhiều commit.
---
### 1.4 Git
- Cài đặt: https://git-scm.com/
- Tools:
- Command line
- https://desktop.github.com/
- https://www.gitkraken.com/
- Dùng giao thức HTTPS hoặc SSH để tương tác với remote repository
---
### 1.4 Git
- Dùng giao thức SSH


---
### 1.4 Git
#### 1.4.1 Sử dụng Git
- Tạo một git local repository
```
mkdir test
cd test
git init
git status
```
- Tạo một file và thêm vào **Staging area**
```
git status
git add myfile.txt
git reset myfile.txt
git status
```
```
git add .
git add myfolder
git reset myfolder
```
---
#### 1.4.2 Staging area
 
Cheatsheet: http://ndpsoftware.com/git-cheatsheet.html#loc=remote_repo;
---
#### 1.4.2 Staging area

---
#### 1.4.3 Staging files
- Audit your work area with your staging area
```
git add -p
```
- Unstaging files can be done in parts too
```
git reset -p
```
- If you want to reset to a GREEN state
```
git checkout myfile.txt
git status
```
- This doesn't affect added files
```
git add -p
git checkout .
git status
```
---
#### 1.4.3 Branches
- Master is the default branch in git
- Create branches with
```
git branch mybranch
```
- Checkout branches with
```
git checkout mybranch
```
- List branches with
```
git branch
```
- Delete branches with
```
git branch -d mybranch
```
---
#### 1.4.4 Rebase and Merge
- Root của nhánh: là commit mà nhánh được tách ra

---
#### 1.4.4 Rebase and Merge
- Fast-forward (FF): Gộp thay đổi từ nhánh feature vào nhánh master mà không tạo thêm commit mới.
 
---
#### 1.4.4 Rebase and Merge
- Fast-forward (FF):
 
---
#### 1.4.4 Rebase and Merge
- Rebase: Dùng để chuyển root của nhánh hiện tại lên commit mới nhất của nhánh mục tiêu
```
git rebase master
```
 
---
#### 1.4.4 Rebase and Merge
- Squash: Gộp các commit lại thành 1 commit
+ Thường dùng chung fast-forward
+ [Cách dùng](https://gist.github.com/shellkore/4ebec03a5893958aa00127d16b20baef)
- Merge request
+ Yêu cầu gộp code từ nhánh hiện tại về nhánh mục tiêu
+ [Cách dùng](https://c.eyeteam.vn/hyundai-viethan/server/merge_requests/new?utf8=%E2%9C%93&merge_request%5Bsource_project_id%5D=81&merge_request%5Bsource_branch%5D=develop&merge_request%5Btarget_project_id%5D=81&merge_request%5Btarget_branch%5D=master)
---
## 2. Workflows
### How branches can be used for workflow

---
## 2. Workflows
### Code reviews

---
### 2.1 Đối tượng tham gia
#### 2.1.1.Dev
- Tách nhánh từ commit mới nhất
- Đặt tên nhánh dễ gợi nhớ đến task thực hiện
- Tạo merge request:
- Rebase nhánh gốc, xử lý conflict
- Push code
- Tạo merge request
- Sau khi tạo, nếu cần thay đổi thì thêm `WIP: ` vào trước title
- Theo dõi và phản hồi với `reviewer`. Luôn chủ động cho tới khi merge request được merge.
---
##### Lưu ý khi tạo merge request:
- **Title**: Đặt theo commit convention
- `feat(parser): add ability to parse arrays`
- **Description**: Mô tả chi tiết các thay đổi
- **Assignee**: Thêm reviewer phụ trách review
- Chọn đúng nhánh cần merge
- Đánh dấu 2 lựa chọn như hình

- Nhấn `Submit merge request`, báo reviewer nếu cần
---
##### Commit message convention
```
<type>[optional scope]: <description>
Eg: feat(parser): add ability to parse arrays
```
> Link: https://www.conventionalcommits.org/en/v1.0.0-beta.4/
- **Type**
- `fix`: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
- `feat`: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
- `BREAKING CHANGE`: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.
- `Others`: commit types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends chore:, docs:, style:, refactor:, perf:, test:, and others.
---
#### 2.1.2. Reviewer
- Review và phản hồi merge request được assign và không có tag `WIP`
- Thực hiện merge fast-forward nếu pass
- Các mục nên review:
- Code convention
- Kiểm tra logic quan trọng
- Tên biến, tên hàm
- Cấu trúc code
- Cấu trúc thư mục
- ...
- Yêu cầu QC test riêng nhánh khi cần
---
#### 2.1.3. QC
- Tự deloy nếu biết
- Test lại nhánh `dev` khi có `MR` được merge
---
### 2.2 Cách xử lý một số usecase
#### 2.2.1 Có nhiều `MR` tại 1 thời điểm
- Sau khi 1 request được merge, cần rebase các `MR` còn lại. Gitlab đã hỗ trợ sẵn nút `rebase` trên giao diện `MR`
- Reviewer tự bấm `rebase` để tiến hành rebase
- Trường hợp xảy ra conflict, reviewer yêu cầu dev tự rebase rồi đẩy lên lại.
---
#### 2.2.1 Có nhiều `MR` tại 1 thời điểm

---
#### 2.2.2 Cập nhật code từ nhánh `dev` sang `master` sau mỗi sprint
- B1: rebase dev lên master
```
git checkout dev
git fetch
git rebase origin/master
```
- B2: Tạo `MR` từ `dev` vào `master`
- B3: Thực hiện merge `FF` như bình thường
---
#### 2.2.3 Hot fix trên `master`
- B1: Tách nhánh từ commit mới nhất của `master`. Đặt tên nhánh:
```
hotfix/[tên nhánh]
```
- B2: Fixbug trên nhánh `hotfix`
- B3: Tạo `MR` từ `hotfix` vào `master`
- B4: Sau khi `MR hotfix` được merge, rebase lại nhánh `dev` lên `master`
---
#### 2.2.4 Xử lý conflict khi rebase
```
git rebase origin/master
...conflict...
xử lý conflict bằng ide, merge tool ...
git add .
git rebase --continue
... xử lý như trên nếu vẫn gặp conflict ...
git push --force
```
---
### Thank you! :sheep: