Câu trả lời:
tôi sử dụng
[Abc]: Message.
Với Add, Mod (ify), Ref (diễn xuất), Fix, Rem (ove) và Rea (khả năng) thì thật dễ dàng để trích xuất logfile.
Thí dụ :
Add: New function to rule the world.
Mod: Add women factor in Domination.ruleTheWorld().
Ref: Extract empathy stuff to an abstract class.
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.
Rem: freeSpeech is not used anymore.
Rea: Removed old TODO and extra space in header.
Nếu tôi có nhiều hơn một dòng, tôi sắp xếp chúng với quan trọng nhất trước tiên.
Modvà Ref? Đôi khi tôi chỉ thực hiện các sửa chữa nhỏ đó là một số loại tái cấu trúc.
Modlà về việc thêm một cái gì đó hoặc thay đổi một hành vi, Reflà về việc thay đổi nội dung không thêm bất kỳ tính chất giả mạo nào, thêm API, v.v. Ví dụ: nếu tôi có một add(Object)chức năng và tôi thực hiện một add(List<Object>)chức năng, tôi sẽ nhận xét Mod. Sau đó tôi loại bỏ trùng lắp và sử dụng trực tiếp add(Object)trong add(List<Object>)sau đó tôi sẽ sử dụng Ref.
Chúng tôi sử dụng như sau:
[Id của Ticket trong JIRA]: [Tin nhắn: Đã làm gì] Ví dụ - ABC-123: Đã thêm khả năng định cấu hình bản trình bày cho từng vùng.
Trong trường hợp này với sự tích hợp phù hợp, bạn sẽ có thể nhận được các tập tin thay đổi / xóa / thêm vào trong trình theo dõi vấn đề của bạn. Tuy nhiên, lưu ý rằng bạn nên ngăn thứ gì đó như ABC-123: Xong hoặc ABC-123: Đã sửa với các bộ lọc nếu có thể.
Có một quy tắc đơn giản, đó là quy ước được theo sau bởi nhiều SCM (nếu không phải tất cả) và bởi hầu hết các công cụ hoạt động với SCM:
Dòng đầu tiên của một thông điệp cam kết là một bản tóm tắt ngắn, trong khi phần còn lại của thông điệp chứa các chi tiết.
Vì vậy, hầu hết các công cụ chỉ hiển thị dòng đầu tiên và hiển thị toàn bộ tin nhắn theo yêu cầu.
Một lạm dụng điển hình của thông điệp cam kết là một danh sách các thay đổi (chỉ viên đạn đầu tiên sẽ được hiển thị). Một lạm dụng khác là viết một tin nhắn chi tiết loooong trên một dòng duy nhất.
Vì vậy, nếu có một điều bắt buộc, tôi sẽ nói đó là độ dài tối đa của dòng đầu tiên.
Cá nhân tôi chưa bao giờ thấy một mẫu cam kết chung đáng sử dụng. Nhận xét cần nói chính xác những gì các cam kết có liên quan đến, ví dụ như tính năng / sửa lỗi hoặc tuyên bố ngắn gọn về lý do thay đổi được thực hiện.
Thông tin về những gì đã cam kết không nên được đưa vào, điều này có thể được xác định bởi hệ thống scm. Thông tin thêm về lỗi / tính năng thuộc về nơi từng lỗi và tính năng được theo dõi.
Khi cập nhật báo cáo lỗi sau khi cam kết, tôi thấy cũng tốt khi nêu bản sửa đổi cam kết cùng với các nhận xét trong báo cáo lỗi. Bằng cách này, bạn có thể tìm đường từ nhận xét cam kết đến báo cáo lỗi và đối với mỗi nhận xét về báo cáo lỗi, bạn có thể tìm thấy những gì đã cam kết, nhưng bạn không sao chép thông tin bằng cách đưa nó vào cả báo cáo lỗi và thông báo cam kết.
Sau đó, khi xem lịch sử sửa đổi cho một tệp, bạn có các thông báo ngắn gọn mô tả lịch sử nhưng cũng biết nơi để tìm thêm chi tiết báo cáo lỗi hoặc mô tả nhiệm vụ để biết thêm chi tiết.
Trong Git, có thể thực thi gần như mọi thứ với móc Git . Kiểm tra các ví dụ trong .git / hook để biết ý tưởng.
Đối với tin nhắn, trong một trường hợp rất chung chung, bạn muốn bao gồm đủ thông tin về vấn đề bạn đang giải quyết VÀ chính giải pháp để có thể tìm và xác định cam kết này sau. Trong hầu hết các trường hợp, sự cố sẽ được tham chiếu số lỗi (tích hợp đúng với hệ thống theo dõi lỗi của bạn). Nếu bạn có các hệ thống khác, quy trình của bạn tích hợp với (như hệ thống theo dõi đánh giá mã), cũng bao gồm các bit thích hợp:
Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.
BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none
NHƯNG bạn muốn giữ nó đơn giản. Nếu không, mọi người sẽ tìm cách gian lận hệ thống và tạo ra các thông điệp cam kết vô dụng.
Chúng tôi sử dụng một mẫu có chứa
Hai cái đầu tiên được bỏ qua hầu hết thời gian (đôi khi cả ba) vì vậy nó không thực sự là một vấn đề lớn.
Tôi thường có mã định danh trong hệ thống theo dõi vé tôi sử dụng hoặc tổng quan cấp cao làm dòng đầu tiên. Sau đó, tôi có điểm "viên đạn" của mục thay đổi cụ thể trong cam kết. Vì vậy, tôi có thể một cái gì đó như:
MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity
Đây là định dạng cam kết sạch nhất mà tôi thích. Nó là trực tiếp và đến điểm. Một lý do khác khiến tôi làm theo cách này là nếu tôi muốn tạo nhật ký thay đổi, tôi có thể lấy tất cả các thông điệp cam kết và phân tích nó thành nhật ký thay đổi rất dễ dàng.
[TicketId] [ABC] [topicId] [WIP] Tin nhắn, trong đó:
Ví dụ:
[# 452567] [add] [menu_item] mục mới - sổ lưu bút
[# 452363] [fix] [banner_top] [WIP] 1024x300 có thể được sử dụng ngay bây giờ
[# 452363] [fix] [banner_top] 500x200 có thể được sử dụng ngay bây giờ
[ # 452713] [rem] [trang] quảng cáo giữa bên trái