E có thắc mắc về cách chia commit khi làm các tính năng có liên quan đến nhau

109 lượt xem

profile picture

Ẩn danh

Ngày 19 tháng 06 năm 2023

Chào các bác. Không biết các bác thường chia commit theo các tiêu chí nào vậy ạ? E đang tham gia build một sản phẩm từ đầu, e cũng muốn viết commit cho từng tính năng, nhưng có những tính năng liên quan đến nhau mà cứ phải viết commit cho từng cái thì cũng hơi phiền... Cá nhân mọi người thường commit như thế nào vậy ạ?

Đánh giá câu hỏi ngay!

Hãy ấn Up Vote với những câu hỏi cụ thể và chi tiết

Hãy ấn Down Vote với những câu hỏi chưa rõ ràng Careerly sẽ nhắc người hỏi chỉnh sửa lại.

3 câu trả lời

BEST

Ảnh đại diện của Tín Nguyễn

Thường khi khởi tạo một dự án, mình nghĩ là không cần quá quan tâm đến việc commit như thế nào ngay lúc đó. Mình hay commit hết tất cả các thay đổi một lượt, với commit message đơn giản là "init project". Khi mọi thứ ổn định rồi, chính là lúc chúng ta bắt đầu thêm các tính năng mới. Thì lúc này tại một thời điểm bạn chỉ có tầm 1-2 tính năng thì bạn có thể hoàn toàn dễ dàng commit theo ý của mình. Cứ tách biệt nó ra thôi, cố gắng tại một thời điểm thì làm một việc, cố chia tách nó ra. Còn về câu hỏi khá specific khi làm 2 tính năng liên quan đến nhau. Nếu mà chúng ta tách nó ra được thì quá tuyệt vời. Còn không thì mình nghĩ là cứ commit 1 lần thôi. Cố gắng nghĩ ra một message chung. Vì tổng quát lại, thì 2 tính năng đó không tách ra được thì phải có lý do chứ, nó phải giải quyết hoặc là một tính năng gì đó. Bạn có thể tham khảo thêm bài viết về cách viết commit message ở dưới nhé. Commit message cũng là một cách để bạn có thể dễ dàng nắm context của các commit trong quá khứ. https://careerly.vn/comments/5598?utm_campaign=self-share

Ảnh đại diện của TrungQuanDev

Thông thường khi đi làm thì trong team sẽ dùng các công cụ quản lý task ví dụ nổi tiếng như Trello, mỗi task sẽ có một title riêng, đảm nhận một tính năng riêng, task to quá thì lại chia ra nhỏ hơn kiểu Phase 1, Phase 2...vv Từ đó mà mỗi khi em làm một task, việc em tạo branch, commit, tạo pull request thì tên của chúng nó cũng linh hoạt để tương ứng với task em đang làm, mỗi task lại sẽ có một id riêng nữa, nên em cũng cho thể viết id của task vào trong commit message - đây là cách mà anh vẫn đang dùng trong công việc hàng ngày, để khi cần thì tìm lại pull code rất nhanh. - Về điều em nói: "có những tính năng liên quan đến nhau mà cứ phải viết commit cho từng cái thì cũng hơi phiền... " thì thật ra cái này bình thường =)) Như đã nói ở trên, tách nhỏ ra, thì thêm chữ Phase 1 phase 2, và id của task vào commit message là xong em =)) - À thêm một kinh nghiệm nữa: thường một pull request anh tạo cho một tính năng thì anh luôn để một commit, nghĩa là từ lần update tiếp theo sẽ dùng commit --amend, chỉ lần đầu mới commit -m "message_here" thôi. Như vậy thì git trees cũng sẽ rất gọn gàng. - Cuối cùng, cứ thoải mái commit, miễn sao đảm bảo sau này cần tìm lại pull code (commit code) của 1 task nào đó thì tìm dễ dàng là được em. - Trước anh cũng từng làm 1 chiếc video: "Git - GitHub - Học để đi làm" ở đây, cho em và các bạn qua đây cần thì tham khảo nhé: https://youtu.be/swlrBlriFPE

Ảnh đại diện của Hùng  Nguyễn Văn

Hùng Nguyễn Văn

FPT Backend DeveloperNgày 27 tháng 08 năm 2023

cảm ơn anh, em vừa xem video của anh xong ạ. Cảm ơn anh nhiều <333

Ảnh đại diện của anh tuan ngo

Thường nếu task quá lớn thì nên cắt thành từng phần riêng biệt vì dù có liên quan nhưng cũng có những thứ riêng, và commit từng phần riêng đấy. Nhìn từ góc độ người commit, bạn sẽ thấy khá tiện khi chỉ 1 2 commit (hoặc amend) cho cả task sửa 20, 30 file. Nhưng ở góc độ người review code, đọc 1 pull request 30, 40 file thì đuối lắm luôn á

Đăng ký ngay bây giờ để đọc toàn bộ câu trả lời!

Cộng đồng lập trình viên sẽ giải đáp tường tận cho bạn.

Xem thêm

Đồng ý với Điều khoản dịch vụ Chính sách bảo mật của Careerly

Bạn đã có tài khoản rồi?

Đăng ký ngay bây giờ để đọc toàn bộ câu trả lời!

Cộng đồng lập trình viên sẽ giải đáp tường tận cho bạn.