In order to improve code quality we have to follow merge request rule.
By Minh Pham, 2020
Để tăng chất lượng code sau khi tách business team thì codebase của android sẽ app dụng rule là phải tạo request merge và được accept bởi reviewer với yêu cầu theo bên dưới:
-
Giai đoạn pick feature vào develop sẽ do lead của business team tạo merge request sau khi đã được pick vào bản release. Trách nhiệm review và accept sẽ do KhanhTM chia ra làm hoặc sẽ chuyển cho chuyên gia khác review.
-
Giai đoạn fix bug, UAT... các team-member tạo merge request vào develop/release_* , việc review và accept sẽ do người owner của feature (lead business team) làm
Trước khi tạo Merge Request (MR):
- Test code đầy đủ
- Dò lại danh sách các commit, các thay đổi line by line (bằng Git UI tool)
Các bước tạo một Merge Request: Gitlab Basics: Add Merge Request
- Click vào button New Merge Request
- Chọn
Source Branchlà bug/feature branch,Target branchlà branch sẽ được merge vào - Chọn Compare branches and continue
Chi tiết một Merge Request:
- Đối với bug mantis: copy Summary của bug mantis
Ví dụ: 12345: [FEA][Compress Video] Optimize time compress video
- Đối với new feature: đặt title ngắn gọn thể hiện rõ tính năng của feature
Ví dụ: Support new chat log
NOTE:
- Có thể dùng WIP để tạo MR ngay khi vừa tách branch và note các discussion, doc... vào để sau này xem lại.
-
Đối với MR fix bug: ghi rõ lí do, hướng xử lí, phạm vi ảnh hưởng của bug
-
Đối với feature: có thể dùng template có sẵn cho new feature, note kĩ spec, documents, trello card, flow cũ như thế nào, flow mới improve gì
Assign cho tác giả của bug/feature. Nếu là chính mình thì dùng Assign to me
Chọn đúng label cho MR (có thể chọn nhiều label).
Các label bắt buộc của một MR:
| Label | Description |
|---|---|
| base | MR sửa code base (thường là code về core) |
| bug | MR fix các loại bug |
| document | MR document |
| feature | MR new feature |
| improve | MR cải tiến một issue |
| optimize | MR optimize code base, performance |
| other | MR khác |
| uat | MR cho các issue được UAT từ product |
| unit-test | MR support unit-test |
Các label diễn tả lifecycle của một MR:
| Label | Description |
|---|---|
| MR: DO NOT MERGE | MR đang wip, hoặc không được merge |
| MR: need review | MR cần review code |
| MR: ready to merge | MR đã pass review, có thể merge dưới sự cho phép của Team Lead |
- Delete source branch when merge request is accepted:
Branch nào sau khi merge mà không được dùng nữa (branch chỉ có 1 UAT, fixbug...) thì chọn thêm option sẽ xóa sau khi merge. NÊN CHECK
- Squash commits when merge request is accepted
Không nên check nếu không hiểu rõ squash là gì. Có thể đọc thêm option này làm gì ở đây. Một lần nữa, KHÔNG NÊN CHECK.
Các bước review code:
- Chọn người sẽ review (với fixbug, UAT...), có thể bổ sung các thông tin cần thiết hỗ trợ review tốt nhất như document, techspec, mantis...
- Tag người sẽ review code vào mục discussion bằng cách
@reviewer_domain. TUYỆT ĐỐI KHÔNG ĐỔI ASSIGNEE. Assignee là tác giả của bug/feature đó, sau này blame dễ dàng hơn. - Thêm label MR: need review
- Báo reviewer biết để review MR này
- Có thể thảo luận trực tiếp trên MR line-by-line, hoặc gặp mặt trước tiếp.
- Discussion nào discuss xong thì nên mark resolve.
Các bước khi pass review:
- Chỉ pass review khi đã resolve all discussions
- Reviewer comment vào discussion thông báo đã pass review
- Reviewer remove label MR: need review và thêm label MR: read to merge_
- Tác giả thông báo với Team Lead MR đã done, có thể merge vào
Target branch
Đối với Team Lead:
- Tiến hành click button Merge khi MR đã done và
Target branch(thường là develop branch) chưa đóng code. - Khi thấy button Rebase thay vì button Merge, khoan click vội, liên hệ với tác giả của MR để xử lý.
Đối với tác giả MR:
Khi nhận được yêu cầu rebase Target branch (thường là develop) để tiến hành merge MR. Có 2 hướng xử lý: git merge hoặc git rebase
- Nếu bug/feature branch chưa merge vào bất kì branch nào: dùng
git rebase develop - Nếu bug/feateure branch đã merge vào ít nhất một branch (thường là branch daily của từng vertical team): dùng
git merge develop
Note:
-
Cả 2 hướng xử lý trên đều phải đảm bảo
Target branch(thường là develop) đã sync code mới nhất trên remote bằng lệnhgit pull origin <target-branch> -
Xem chi tiết hướng xử lý
git mergevàgit rebaseở đây