- vừa được xem lúc

Pull request description cần có những gì?

0 0 11

Người đăng: Nguyễn Xuân Tài

Theo Viblo Asia

Hê lô các bác, lại là em đây 🤡

Hôm nay em sẽ nói về 1 chủ đề đó là: Pull request's description cần có những gì?

Mục description của PR rất hữu ích cho việc ghi chú các thông tin cần thiết, để cho việc tracking task được tốt hơn. Ngoài ra, sau này khi tìm kiếm lại một PRs và tìm kiếm các thông tin liên quan cũng sẽ dễ dàng và nhanh chóng hơn, tránh bị thiếu sót khi kiểm tra

Hiện tại thì em cũng đang apply template này cho dự án mình đang làm, nếu các bác có gì bổ sung hoặc thấy thừa thì có thể góp ý nhé

1. Related PRs:

Hiện nay có rất nhiều dự án có dùng nhiều hơn 1 repos. Hoặc cũng do tính chất của dự án mà 1 task có thể có nhiều PRs. Vì thế mình sẽ cần tới mục này để list các PRs liên quan tới task.

2. Attention!:

Chỗ này em cũng ko biết dùng từ thế nào cho phù hợp, nên để thế thôi 🤡. Mục đích của nó thì quá rõ rồi. Chỗ này mình sẽ remind các công việc cần thiết cần chuẩn bị trước do việc release task. Nó có thể là setting ENV, chạy compile, sửa lại những dòng code đang sử dụng cho môi trường test,... Nói chung là những điều quan trọng cần lưu tâm trước khi release.

Lưu ý nhỏ là mình chỉ dùng mục này như 1 reminders thôi nhé, chứ đừng note cụ thể quá. Lỡ lộ access_key AWS thì ốm đòn, các bác tự chịu trách nhiệm nhé 🤡

3. Summary:

Chỗ này thì đơn giản là mình sẽ viết mô tả một cách ngắn gọn về task mà mình đang làm để người review có thể nắm bắt sơ bộ nội dung của task. Nếu người ta muốn biết rõ hơn thì sẽ xuống mục dưới để xem specs 😁

4. Link specs

Thông thường, KH sẽ luôn quản lý các task qua các ứng dụng như Jira, Trello, Backlog. Nhưng đôi khi họ sẽ define specs mỗi lúc một kiểu, và vì thế việc tìm kiếm lại specs sẽ khá khó khăn cho chúng ta. Nên việc thêm link specs vào PR cũng là điều cần thiết

5. Output

Mục này thì chủ yếu là evidence là mình đã hoàn thành task thế nào thôi. Giúp cho reviewer dễ dàng so sánh giữa specs và kết quả có giống nhau hay ko. Tất nhiên muốn kĩ hơn thì vẫn phải test manual rồi 🤡

Dưới đây là mẫu template mà em đang sử dụng

## 1. Related PRs
- Link related PRs or _No related PRs_
## 2. Attention!
**These are things you need to get done before release to production. Please read it carefully!**
- _write here_
## 3. Summary(short description about PRs's goal)
- _write here_
## 4. Link specs
- _write here_
## 5. Output(Image, video, JSON example)
- _write here_

Tổng kết

Có thể các thông tin trên chưa được hợp lý lắm, tuy nhiên em sẽ tiếp tục sử dụng và cải thiện nó tốt hơn. Các bác có đóng góp hay gạch đá gì cứ quăng vào đây hết nhé. Em sẽ sử dụng hợp lý tất cả những gì được trao 😄

Bình luận

Bài viết tương tự

- vừa được xem lúc

Học Regular Expression và cuộc đời bạn sẽ bớt khổ (Updated v2.2)

. Regular Expression (RegEx) à? Nghe quen quen. . Bạn cần xử lý validate (kiểm tra tính hợp lệ) các trường dữ liệu nhập vào ô Text. .

0 0 93

- vừa được xem lúc

Tóm tắt cuốn Clean Code của Uncle Bob

Bài viết được dịch từ Gist của wojteklu. . Quy tắc chung. .

0 0 92

- vừa được xem lúc

biết về HEAD và Detached HEAD trong GIT để tránh bị mất code

rất nhiều trường hợp các bạn không biết code của mình mới commit đã đi đâu. Đây là kinh nghiệm xương máu của mình về cách dùng Git, hồi đó còn non và xanh không biết gì nên cũng hay dính Detached HEAD

0 0 47

- vừa được xem lúc

Làm thế nào để hạn chế conflict khi làm việc với GIT

Define cấu trúc source code, modulle hoá ngay từ sớm: để tránh conflict thì việc quan trọng nhất vẫn là hạn chế tối đa việc code chung một file, một dòng. Các bạn nên chia nhỏ ứng dụng thành các modul

0 0 51

- vừa được xem lúc

Cơ bản về Gitflow Workflow

Giới thiệu. Gitflow Workflow là một thiết kế quy trình làm việc được sử dụng lần đầu tiên và làm cho phổ biến bởi Vincent Driessen at nvie.

0 0 22

- vừa được xem lúc

Trunk Based Development - một Git workflow giúp giảm cơn đau đầu resolve conflict

Case study. Câu chuyện đầu tiên.

0 0 12