Presentation about Git Concept, not Git Command

1. Quản lý source code với Git
tienhm@eway.vn

2. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning

3. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning

4. Khái niệm
- Là hệ thống quản lý phân tán phiên bản source code (distributed version-control
system) phát triển bởi Linus Torvalds vào năm 2005.
- Được thiết kế như một công cụ để các Lập trình viên có thể cộng tác cùng nhau
trên một source code.
- Hầu hết các công ty công nghệ đều đang sử dụng git.

5. Version Control System (VCS)
- Thay đổi là liên tục
- Đôi khi thay đổi hiện tại là không thoả
mãn, cần bỏ đi
- Đôi khi phiên bản trong quá khứ quan
trọng hơn
- Đôi khi có nhiều người cùng làm việc
trên 2 phiên bản khác nhau
→ Cần có một hệ thống quản lý phiên bản
để thống nhất về

6. Centralized VCS vs Distributed VCS
CVCS DVCS

7. Centralized VCS vs Distributed VCS
CVCS DVCS

8. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning

9. Cách chia vùng
- Git chia ra 2 môi trường: Môi trường
Phát triển (là môi trường phát triển
của lập trình viên), và môi trường
Server (GitHub, GitLab, …)
- Môi trường phát triển được chia thành
3 vùng: Working Directory, Staging
Area, Local Repository.

10. Clone
- Fork repo: https://gitlab.com/tienhm/git-
training
- Clone repo vừa fork về, trong đó sẽ có 2
file ví dụ pet.php và docs.md

11. Changes
- Đơn vị nhỏ nhất Git quản lý là đối tượng
Changes.
- Changes có 3 loại:
- added: Khi thêm 1 file mới
- deleted: Khi xoá 1 file
- modified: Khi thay đổi nội dung file
(changes dạng này có thể tính đến
đơn vị dòng)
- Working Area là nơi xuất phát của
Changes
- Các file trong Working Area sẽ được
đánh dấu là Tracked hoặc Untracked
(Untracked là file mới - trong repository
chưa có, git chưa biết về file này)

12. Add Changes
- Commit được cấu thành bởi một hoặc
nhiều Changes
- Commit cần đủ nhỏ để có thể mô tả
- Chỉ chọn các Changes phù hợp với
Commit
- Lưu ý: với Changes dạng modified, có
thể lựa chọn tới từng dòng, nên hãy cố
gắng tỉ mỉ khi lựa chọn.

13. Commit
- Không được viết Commit message quá
chung chung (Kiểu như “Update code")
- Nếu nhiều Commit cùng làm 1 việc và
phát sinh sau trong quá trình phát triển
thì cần dọn dẹp (Clean History)
- Nếu bạn có quá nhiều Commit cho 1 tính
năng thì: hoặc là task đó quá lớn, hoặc
là commit chưa đúng
- Có thể coi mỗi Commit là 1 bước để
hoàn thành task.
- Nếu dự án của bạn chia thành các
components, Commit nên chia thêm
theo chiều scope của components.

14. Push
- Push là bước để Remote Repository cập
nhật thay đổi từ Clients
→ Việc này có thể sinh ra Conflicts khi 2
người cùng sửa 1 dòng ở cùng 1 file (race
condition)

15. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning

16. Git Workflow
1. Centralized Workflow
2. Feature Branching
3. Forking Workflow
4. Git Flow
5. GitHub Flow

17. Luồng làm việc cơ bản
1. Bạn cần làm tính năng mới → Tạo branch tương ứng
2. Sau khi làm xong cần tự hoàn thiện code của mình (tự test nhiều case nhất có thể, xoá các đoạn
code debug, clean git history..)
3. Tạo yêu cầu merge
4. Sửa các góp ý phát sinh trong quá trình review
5. Merge code sau khi review

18. Branch (1)
- Cần chia ra 2 loại branch: private
branch và public branch
- Public Branch:
- Dùng chung bởi nhiều người
- Tương ứng với môi trường (ví dụ:
master tương ứng với production,
dev tương ứng với dev,...)
- Có bao nhiêu môi trường thì tạo
ngần ấy Public Branch
- History trên public branch là fact,
không ai được phá huỷ. Các hành
động merge trên Public Branch do
đó cần làm cẩn thận và theo quy
trình.

19. Branch (2)
- Cần chia ra 2 loại branch: private
branch và public branch
- Private Branch:
- Là branch để làm 1 tính năng - nên
chỉ do 1 người làm.
- Cần tuân thủ commit message
- Trước khi merge, có thể rebase để
dọn dẹp history (nếu cần)

20. Rebase (1)
- Rebase trước khi merge để tránh
conflict
- Rebase xong thì phải `git push -f` để
forced rewrite.

21. Rebase (2)
- Rebase sinh ra để Rewriting History. Mục đích là để có một History sạch sẽ. Giữ lại tri thức của dự
án về sau.
- Rebase rule:
- Public Branch: Không được rebase trên đây - do là branch dùng chung. Làm như vậy sẽ ảnh
hưởng tới nhiều người. Nếu bạn làm sai ở Private Branch mà vẫn merge vào Public Branch thì
quá trình Review code không hiệu quả.
- Private Branch: Luôn chủ động rebase trước khi merge. Nếu cần thiết, hãy thêm việc rebase
vào review checklist để chắc chắn nó được thực hiện trước khi merge. Hãy đảm bảo bạn
không đóng góp một đoạn code vào dự án mà không ai hiểu bạn muốn làm gì.
- Rebase quá nhiều không làm mọi việc tốt hơn vì nó làm cho tất cả những test trước đó của bạn là
vô nghĩa → Cần làm lại test
→ Tham khảo: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

22. Dirty history

23. Clean up history

24. Merge Request Template
- Template cần các phần sau đây:
- Mô tả về feature: Để người review
không mất thời gian tìm hiểu lại vấn
đề
- Test plan: Để người review có thể
test nhanh nhất
- Review checklist: Để người review
không quên các mục quan trọng cần
làm
→ Lưu ý: Người tạo Merge Request (MR)
nên tự review cho mình trước khi assign cho
người khác. Vừa tăng tính hoàn thiện của
MR, vừa dễ dàng nhìn thấy khuyết điểm của
mình để sửa.

25. Nội dung
1. Git là gì ?
2. Thành phần và cách hoạt động
3. Cộng tác trong team
4. Versioning

26. Release
- Thống nhất điểm “sẵn sàng để release" trong cả team
- Ví dụ: merge vào master, build xong, ...
- Dịch vụ cần được đánh version khi release
- Nên tuân theo chuẩn Semantic Versioning
- Hãy viết change logs một cách tận tâm
- Cần nhất là các thay đổi sẽ release trong phiên bản này
- Nếu được, cần có thêm các bằng chứng như build status, test result...

27. Good changelogs

28. Bad changelogs

29. Tóm lại
- Tạo commit hợp lý
- Dọn dẹp git history trước khi yêu cầu merge (rebase)
- Review cần thận trước khi merge
- Đánh version khi đóng gói sản phẩm để release
- Viết changelogs cho các bản release