Thông điệp cam kết nên được viết ở thì hiện tại hay quá khứ? [đóng cửa]

Vì vậy, đó là nó mà bạn nghĩ là tốt hơn và trực quan hơn?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Vui lòng cung cấp lý do của bạn. Lưu ý rằng tôi đang hỏi từ quan điểm chung của bạn, có nghĩa là bạn không nên cố gắng liên kết điều này với các công cụ svn / cvs hoặc ngôn ngữ lập trình ưa thích của bạn, mà hãy nghĩ về nó như một thứ nên / có thể áp dụng cho bất kỳ công cụ và ngôn ngữ lập trình nào.

Tôi nghĩ về những thông điệp này khi chúng xuất hiện với các nhà phát triển khác. Họ vẫn chưa áp dụng các thay đổi và có một câu hỏi ngầm là "áp dụng bộ thay đổi / bản vá này sẽ làm được gì?" Nó sẽ "Sửa lỗi XXX trong YYY"!

Đối với các động từ khác, việc viết chúng dưới dạng lệnh có vẻ tự nhiên hơn và hoạt động tốt hơn nếu bạn có một mục tiêu cụ thể — bạn có thể viết tóm tắt cam kết theo đúng nghĩa đen cùng với các bài kiểm tra trước khi hoàn thành công việc.

Tôi không đặt nặng vấn đề, nhưng đối với tôi đây là con đường ít kháng cự nhất trong khi vẫn duy trì được tính nhất quán.

Cá nhân tôi đi với thì quá khứ ("đã sửa") vì thời điểm tôi phạm lỗi đã được sửa (hoặc tôi sẽ không phạm).

Tôi muốn xem thông báo cam kết ở thì hiện tại. Bằng cách đó, thông báo mô tả những gì khác biệt thực hiện (vì bạn có thể kéo sự khác biệt đó hoặc thậm chí toàn bộ cam kết đó vào một nhánh khác). Do đó, thông điệp cam kết không mô tả những gì nó "đã" làm ... Nó mô tả những gì chính bản thân cam kết "làm" làm. Vì vậy, nó nên ở thì hiện tại.

Hãy tưởng tượng bạn đang nhìn vào một điểm khác biệt và cố gắng quyết định xem bạn có áp dụng nó hay không. Nó không có ý nghĩa gì nếu nó có một tiêu đề ở thì quá khứ.

IMHO nếu bạn muốn nó mang tính mô tả mà không cần xem xét ngữ cảnh, thì "Fixed" chắc chắn là biến thể phù hợp duy nhất.

Về tính trực quan - nếu tôi nhìn vào một số thay đổi, tôi chắc chắn sẽ hiểu rằng ý bạn là lỗi đã được sửa vì tôi biết ngữ cảnh mà từ đó được sử dụng, nhưng não của tôi sẽ nắm bắt nó nhanh hơn nhiều nếu từ đó được viết theo kiểu này- xác định cách.

"Sửa" là lựa chọn tồi tệ nhất IMHO vì nó có thể được hiểu không chỉ là mô tả những gì bản vá làm (dành cho) mà còn là trạng thái lỗi cũng có nghĩa là nó đang được hoạt động và chưa được giải quyết.

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

Nói chung: {imperative verb} {đối tượng bị ảnh hưởng} {các định nghĩa tùy chọn}

Hình thức bắt buộc phù hợp với tất cả các trường hợp sử dụng khi tôi đang xem xét một bộ vá.

• Bạn định làm gì ở đây?
• Patchset này làm gì?
• Tại sao bộ vá này được tạo ra? (để sửa lỗi xxx ...)
• Tôi cần sửa lỗi xxx trong yyy. Có một cam kết trên một nhánh khác đã thực hiện điều này chưa?

Bất kể lựa chọn của bạn là gì, tôi nhận thấy tính nhất quán giúp khả năng đọc rất nhiều. Chọn một cái và gắn bó với nó.

Tôi nghĩ rằng viết về cam kết hiện tại ở thì hiện tại là một ý tưởng hay, bởi vì nó làm cho nó rõ ràng hơn khi bạn đề cập đến các cam kết trước ở thì quá khứ.

Tôi không nghĩ nó thực sự quan trọng. Mục đích là:

1) Truyền đạt những gì đã hoặc đang được thực hiện, do đó, lỗi có thể được tìm thấy dễ dàng hơn, các vấn đề có thể được hoàn nguyên dễ dàng hơn và nói chung có thể duy trì dự án dễ dàng hơn.

2) Chuyển tải những vé nào đã được sửa nếu có, vì vậy người kiểm tra (nếu chúng được sử dụng trong công ty của bạn có thể xem những thay đổi nào tương ứng với những vé nào).

Cuối cùng, nếu nó 'đã được sửa, thì "Fixing" không có ý nghĩa gì và nếu bạn vẫn đang làm việc đó, thì "Fixed" là không chính xác.

" Sửa lỗi X " ngắn hơn 2 ký tự so với "Đã sửa lỗi X ".
Và ngắn hơn 3 so với " Sửa lỗi X ".

Theo quan điểm của việc viết-ngắn-cam-kết-thông điệp, thì hiện tại đôi khi / thường lưu một vài ký tự?
Điều mà tôi thực sự nghĩ hơi quan trọng một chút, ví dụ như với đề xuất của Git về dòng tin nhắn dưới 50 ký tự-trên-đầu-tiên-cam kết.
Ngoài ra, ít văn bản hơn -> đọc xong nhanh hơn?

Thông báo cam kết mô tả lý do tại sao bạn viết mã đang được cam kết.

"Đã khắc phục sự cố 3124" hoặc "Khắc phục sự cố 3124" có vẻ đúng vì mã này cho biết mã này đã sửa | khắc phục sự cố 3124.

Tuy nhiên, ngữ pháp cũng có thể phụ thuộc vào lý do tại sao đánh dấu lỗi là đã sửa. Nếu bạn có thể đánh dấu lỗi là đã sửa sau khi cam kết, thì "Đã sửa" là tốt, nhưng nếu lỗi sẽ được người khác đánh dấu là đã sửa sau khi họ xác minh mã của bạn, thì "Sửa" có thể phù hợp hơn.

Tôi nghĩ câu trả lời quan trọng nhất cho câu hỏi như vậy là: Mọi người nên sử dụng những gì hiệu quả cho một dự án cụ thể và giữ cho nó ít nhất một chút nhất quán.

Mặc dù tôi thấy những lợi thế của việc sử dụng thì hiện tại (và thực tế là tôi đã tình cờ đọc được bài viết này vì tôi đã thấy một số thông điệp thì hiện tại trong các dự án mã nguồn mở), nhưng có lẽ tôi sẽ không bao giờ sử dụng thì hiện tại cho các dự án của mình. Đó là cách được khuyến nghị cho Linux và Git, và có thể là các dự án nguồn mở lớn hơn khác, nhưng thành thật mà nói thì tôi không quan tâm chừng nào tôi không phải là một phần của những dự án này.

Tôi là một nhà phát triển độc lập và tôi sử dụng dòng đầu tiên của thông báo cam kết cho các ghi chú phát hành trong khi mô tả ở những dòng sau cho tôi ý tưởng về chi tiết triển khai. Đó là quy trình làm việc tập trung vào người dùng so với phương pháp tiếp cận dựa trên nhà phát triển thì hiện tại. Tôi có thể tiết kiệm thời gian bằng cách này. Sẽ vô cùng mất tự nhiên khi cung cấp cho người dùng của tôi hướng dẫn trong ghi chú phát hành. Công việc của tôi là sửa lỗi và thêm các tính năng. Tôi phải tiết kiệm thời gian, bởi vì tôi là một người độc lập. Tôi không có “người viết ghi chú phát hành” trong nhóm của mình.

Sử dụng các quy tắc của một dự án nếu chúng đã được thiết lập, nhưng hãy thực dụng và làm bất cứ điều gì sẽ giúp công việc của bạn dễ dàng hơn hoặc nhanh hơn.

Tôi nghĩ "Fixes XXX bug"có ý nghĩa hơn "Fix XXX bug"nếu lý do sử dụng thì hiện tại là để "làm cho nó mô tả nhiều hơn về những gì người cam kết thực hiện" hơn là những gì người cam kết đã làm.

Nếu nó là một cam kết nhỏ, tôi sử dụng thì hiện tại liên tục:

Sửa lỗi 304

hoặc là

Thêm nhận xét

Nếu đó là một cam kết lớn, tôi thực hiện thêm nhật ký thay đổi:

• Sửa lỗi 453, 657 và 324
• Thêm cú pháp biểu thức
• Đã cấu trúc lại lớp Toán tử.