Là tham chiếu đến lỗi / vấn đề trong thông điệp cam kết được coi là thực hành tốt?

11

Tôi đang làm việc trong một dự án nơi chúng tôi có thiết lập kiểm soát nguồn để tự động viết ghi chú trong trình theo dõi lỗi. Chúng tôi chỉ cần viết ID vấn đề lỗi trong thông báo cam kết và thông báo cam kết được thêm vào dưới dạng ghi chú cho trình theo dõi lỗi.

Tôi chỉ có thể thấy một vài nhược điểm cho thực hành này. Nếu đôi khi trong tương lai, mã nguồn được tách ra khỏi phần mềm theo dõi lỗi (hoặc các lỗi / vấn đề được báo cáo bằng cách nào đó bị mất). Hoặc khi ai đó đang tìm kiếm trong lịch sử cam kết nhưng không có quyền truy cập vào trình theo dõi lỗi của chúng tôi.

Câu hỏi của tôi là nếu có một tham chiếu lỗi / vấn đề trong thông điệp cam kết được coi là thực hành tốt? Có một số nhược điểm khác?

programming-practices version-control issue-tracking

— Christian P
nguồn

10

Chúng tôi đã áp dụng thực hành này và nó hoạt động rất tốt cho chúng tôi. Sự tích hợp chặt chẽ giữa hệ thống kiểm soát phiên bản (VCS) và các hệ thống khác mà chúng tôi sử dụng, ví dụ như tích hợp liên tục, theo dõi lỗi, v.v ... là vô cùng quý giá. Nếu chúng tôi thay đổi bất cứ điều gì trong tương lai, chắc chắn chúng tôi sẽ phải đánh giá các tác dụng phụ, bao gồm các liên kết giữa VCS và hệ thống theo dõi lỗi.

Nói chung tôi sẽ xem đây là thực hành tốt. Đối với một số hệ thống theo dõi, có sẵn các tùy chọn và công cụ bổ sung, ví dụ: thuộc tính bugtraq cho Subversion (SVN). Điều này cho thấy khá nhiều người thấy giá trị trong thực tiễn này.

— Manfred
nguồn

13

Nếu bạn muốn thực sự, thực sự chắc chắn rằng không có thông tin nào bị mất ngay cả khi bạn có thể sử dụng trình theo dõi lỗi khác trong tương lai hoặc dữ liệu theo dõi lỗi của bạn bằng cách nào đó biến mất, tại sao không đặt cả ID vấn đề và giải thích ngắn về lỗi vào thông điệp cam kết?

Sửa lỗi # 123: ứng dụng bị sập sau khi đăng nhập

Sau đó, bạn vẫn có liên kết từ lịch sử cam kết với trình theo dõi lỗi - và nếu trình theo dõi lỗi không bao giờ có sẵn, bạn vẫn có thể thấy trong lịch sử lỗi này là gì.

— Christian Specht
nguồn

Chúng tôi thực sự làm điều đó, vì vậy chúng tôi không phải chuyển sang theo dõi lỗi mỗi khi chúng tôi duyệt qua lịch sử của các cam kết.

— Christian P

Được rồi, sau đó tôi sẽ để nó như vậy. IMO, đây là cách tốt nhất để bạn có thể làm điều đó!

— Christian Specht

1

Vâng, điểm tốt. Dù sao đó cũng là giả định của tôi. Chỉ một mình ID lỗi / vấn đề là không đủ tốt theo kinh nghiệm của tôi. Nhìn vào nhật ký cam kết, bạn vẫn muốn xem mỗi cam kết là gì, ví dụ lý do rộng của việc thay đổi mã này là gì. Đôi khi, thông điệp cam kết có nhiều hơn về mặt kỹ thuật trong khi văn bản cho hệ thống theo dõi lỗi sẽ hướng nhiều hơn đến người dùng phần mềm.

— Manfred

Đây thường là cách thực hành tiêu chuẩn nơi tôi đã làm việc, tôi nghĩ rằng đó là cách đúng đắn để làm điều đó.

— Carson63000

+1 luôn làm điều này! Tôi vừa mới bảo trì một dự án chứa đầy đá quý như "đây có thể là nguyên nhân gây ra lỗi 5423" Chúng tôi không có quyền truy cập vào trình theo dõi lỗi của họ.

— Kryptic

2

Đây là thực tế rất phổ biến, và tôi đã tìm thấy nó vô cùng thuận tiện. Tôi sử dụng TRAC, vì vậy tôi có thể đọc lịch sử mã và điều hướng đến tác vụ thúc đẩy thay đổi hoặc đọc lịch sử tác vụ và điều hướng đến các thay đổi mã.

"Nếu đôi khi trong tương lai ..." Nếu bạn tách mã khỏi trình theo dõi lỗi, thì lịch sử sửa đổi cũ có thể sẽ không được quan tâm thêm.

— kevin cline
nguồn

2

Tôi cũng sử dụng thực hành này và tôi coi nó là một thứ rất tốt. Nhưng bên cạnh ID vấn đề, tôi thêm một mô tả ngắn về lỗi / tính năng (thường là tiêu đề từ hệ thống theo dõi lỗi). Điều này thường giúp tiết kiệm thời gian vì tôi không phải tìm kiếm trong hệ thống theo dõi lỗi (beacuse tôi nhận ra sự thay đổi) VÀ, như bạn đã nói, nếu bằng cách nào đó tôi mất hệ thống theo dõi lỗi, tôi không hoàn toàn bị mất.

— Nicolae màn
nguồn