Chiến lược trích thông điệp của hầu hết các cam kết hữu ích để changelog

Question

Nhu cầu cho câu hỏi này là để

• có một thay đổi cho các nhà quản lý/khách hàng rằng:
  • không bao gồm "Hãy để người dùng có địa chỉ bổ sung"
  • không bao gồm "Cố định lỗi nơi các địa chỉ được ghi đè do X"
• tránh phải xem xét toàn bộ nhật ký lịch sử để tìm các cam kết quan trọng nhất (thường xuyên nhất ngược không tương thích) cho mỗi xây dựng
• làm cho nó như dễ đọc như changelog trò chơi điển hình ("Cố định vấn đề cân bằng: X" và "Đồ họa tài xế Y rendered trò chơi chậm ")

Hôm nay, chúng tôi đang sử dụng cờ trong bài viết cam kết như

Add|Ref|Rem|Fix: <msg> cho thông thường cam kết.

Như vậy, đâm đầu tiên của tôi ở đây sẽ có thêm tầng khác để những lá cờ, ví dụ

CL-Add: feature X (CL = changelog) và sau đó phân tích tất cả các tin nhắn cho ^CL-(Add|Ref|Rem|Fix) cam kết để thêm vào changelog.

Nhưng sau đó, làm cách nào bạn tiếp cận khả năng có thư cam kết được viết chỉ dành cho các thay đổi (ví dụ: mức quá cao); hoặc nhiều tin nhắn liên quan đến cùng một vấn đề changelog. Có lẽ các thông điệp changelog thay vì được trích xuất khi các đối tượng địa lý được hợp nhất? Có các tính năng của SCM: s (ví dụ git) xử lý vấn đề này cho bạn không?

Đơn giản chỉ cần đặt: có một chiến lược hoặc công cụ chuẩn công nghiệp để trích xuất các thông điệp cam kết hữu ích vào các danh sách thay đổi một cách dễ dàng không?

Answer 1

Tôi đã thử bản thân mình với chút may mắn trong quá khứ. Về cơ bản, nó thực sự là hơn làm việc để mọi nhà phát triển nghĩ, đối với mọi cam kết, về việc liệu thông điệp cam kết của họ có quá đáng sợ cho khách hàng hay không. Các nhà phát triển nói chung không phải là người thích hợp để đưa ra quyết định đó, và làm một chút tại một thời điểm là không hiệu quả. Sau nhiều thử nghiệm, những gì đã làm việc cho tôi là tầm thường: ngay trước mỗi lần phát hành, có một người đi qua nhật ký git kể từ lần phát hành cuối cùng và ghi lại tất cả những thứ thú vị vào một tập tin thay đổi. Điều này thực sự không hiệu quả hơn cách khác; hầu hết các công việc là quyết định, không phải là phrasing. Và quá trình quyết định đòi hỏi một tư duy đặc biệt, do đó, nó có hiệu quả hơn để có một người làm điều đó trong một lô lớn hơn một nhóm các nhà phát triển làm một chút tại một thời điểm. (Hãy suy nghĩ theo cách này: bạn không cần phải tiếp tục hoán đổi phần "kiểm tra thư cam kết của khách hàng" một phần công việc vào và ra khỏi bộ nhớ đệm.)

Nếu bạn thực sự muốn gắn thẻ thư cam kết với loại thông tin này , ít nhất bạn nên cân nhắc thực hiện nó với git notes thay vì thông báo cam kết thô. Sau đó, nếu ai đó vít nó lên bằng cách đánh dấu các cam kết không chính xác như lỗi/tính năng/etc, bạn có thể sửa chữa nó bằng cách cập nhật các chú thích.

Answer 2

Tôi không biết về bất kỳ công cụ tiêu chuẩn như vậy, nhưng kể từ khi bạn đã không nhận được câu trả lời cho một thời gian, đây là một số ý tưởng:

Vì vậy, đầu tiên, cố gắng để tránh một file CHANGELOG, như bạn đề nghị, có lẽ là một ý tưởng tốt nói chung vì tất cả các xung đột hợp nhất như một tập tin có xu hướng gây ra. (Trừ khi bạn xảy ra để có một công cụ hợp nhất tự động thông minh.)

Giống như tiền tố CL: hoặc Log: để dễ dàng trích xuất có lẽ là một ý tưởng hay. Về Thêm/Ref/Rem/Fix: (Tôi giả định rằng Ref và Rem là viết tắt của "Refactor" và "Remove", phải không?) Khi bạn đang viết một changelog, tôi muốn gắn bó với các mục nhập dạng tự do. Ví dụ, tôi không chắc chắn rằng các phép tái cấu trúc thuộc về một thay đổi và các tính năng đủ cao để đảm bảo các mục nhập thay đổi thường không bị loại bỏ hoàn toàn - chúng thay vào đó được thay đổi thành một dạng khác.

Nhưng sau đó, cách bạn tiếp cận khả năng có thư cam kết được viết chỉ dành cho các thay đổi (tức làmức độ quá cao);

Tôi muốn nói, đặt mô tả cấp cao (CL:-được gắn thẻ) trong một đoạn của thông báo cam kết và mô tả kỹ thuật cấp thấp hơn trong một đoạn khác.

hoặc nhiều thư liên quan đến cùng một vấn đề thay đổi.

Chúng ta đang nói về điều gì đó như thế này, phải không?

1. (2011-01-03) CL: Thay đổi whizbar mặc định 200.
2. (2011-01-11) CL: Thay đổi whizbar mặc định 150, hoặc 250 nếu foosnub là đúng.

Và đây là nơi tôi nghĩ điều "thay đổi tự động" trở nên phức tạp. Trừ khi bạn sẵn sàng rebase và chỉnh sửa thông điệp cam kết sau khi thực tế (như loại bỏ "CL:" từ cam kết (1) ở trên), tôi đề nghị rằng cách thực tế duy nhất để đi về điều này là, mỗi khi bạn thực hiện một bản phát hành , để trích xuất tất cả các đoạn được gắn thẻ từ nhật ký git kể từ lần phát hành cuối cùng của bạn và chỉnh sửa danh sách kết quả theo cách thủ công, kết hợp những thứ như (1) và (2) ở trên với nhau và quay, "Cố định # 145", "Cố định # 153 "," Cố định # 164 "thành một dòng" Cố định # 145, # 153 và # 164 ".

Hy vọng tôi có thể cung cấp một số nguồn cảm hứng. Hãy cho chúng tôi biết những gì bạn sẽ làm!

Answer 3

Hãy xem vclog.