Tôi đã là người đi lại duy nhất trong dự án TXR và đã giữ ChangeLog chi tiết từ khá sớm trong dự án. Con số này dài gần 11.000 dòng và đang phát triển:
http://www.kylheku.com/cgit/txr/tree/ChangeLog
(Các thông điệp cam kết trong repo chỉ là một bản sao của những gì diễn ra trong ChangeLog.)
[Chỉnh sửa năm 2016: kể từ giữa năm 2015, tôi không còn duy trì tệp ChangeLog; tuy nhiên, các thông điệp cam kết được viết theo định dạng phù hợp với các quy ước Git và ChangeLog cùng một lúc. Cùng một mức độ chi tiết là ở đó, theo cách không gây ra vấn đề hợp nhất. Một tệp ChangeLog có thể được xây dựng lại một cách cơ học từ những bình luận này.]
Có, hơn một lần tôi đã quay lại một thông điệp cam kết cũ liên quan đến một thay đổi đã phá vỡ một cái gì đó (được phát hiện với sự trợ giúp của git bisect). Thông điệp đã giúp tôi hiểu được những gì tôi đang làm.
Trong ChangeLog, bạn có thể biết khi nào một hàm, loại, macro hoặc biến toàn cục được giới thiệu lần đầu tiên và khi nào nó được chạm vào bởi các thay đổi.
Nhưng lý do chính để viết các thông điệp cam kết chi tiết như thế này khi làm việc một mình là thế này: bạn tìm thấy lỗi khi làm việc này .
Để viết một thông điệp cam kết chi tiết có lợi ích tương tự như đánh giá mã về cam kết của bạn bởi người khác. Giá trị trong đánh giá cam kết không nhiều đến nỗi ai đó đang kiểm tra mã của bạn, nhưng bạn phải giải thích các thay đổi của mình cho nhà phát triển khác.
Khi bạn cố gắng giải thích mọi thứ, đôi khi bạn thấy rằng chúng không có ý nghĩa.
Một lý do khác: bạn có thể bắt mình thực hiện một thay đổi vô ích . Bằng cách viết một bình luận cam kết chi tiết, bạn có được một cái nhìn ở mức độ cao về những gì bạn đang làm, và đôi khi bạn phải đối mặt với thực tế rằng đó không phải là một thay đổi tốt.
Đôi khi tôi đã thực hiện các thay đổi, khi đang viết mục ChangeLog, tôi nhận ra rằng đây sẽ là một git reset --hard(vứt bỏ những thay đổi vô dụng này) chứ không phải là git commit -a.