你可以將變更日誌視為概念上的「還原列表」，它說明了早期版本與目前版本有何不同。人們可以看到目前的版本；他們不需要變更日誌來告訴他們裡面有什麼。他們希望從變更日誌中獲得的是對早期版本差異的清晰解釋。變更日誌中的每個條目描述的是一個單獨的變更，或是屬於一起的最小批量變更，也稱為變更集。
最好在變更日誌條目的開頭加上標題行：單行且完整的句子，總結變更集。如果你將變更日誌保存在 VCS 中，這應該是一個要求，因為 VCS 指令會以縮寫形式顯示變更日誌，例如 git log --oneline，會特別處理標題行。（在 ChangeLog 檔案中，標題行接在說明變更作者以及安裝時間的行之後。）
在變更日誌條目的標題行之後，接著描述整體變更。描述的長度應足以清楚說明。特別注意變更集中不易從 diff 或修改過的檔案和函數名稱中獲取的方面：變更的整體概念和需求，以及對不同檔案/函數所做變更之間的關係（如果有的話）。如果變更或其原因在某些公共論壇（例如專案的問題追蹤器或郵件列表）上討論過，最好在變更的描述中總結該討論的要點，並包含指向該討論或問題 ID 的連結，方便想要完整閱讀的人參考。
解釋新程式碼的各部分如何與其他程式碼協同運作的最佳位置是在程式碼的註解中，而不是在變更日誌中。
如果你認為某個變更需要解釋為什麼需要這個變更——也就是說，舊程式碼有什麼問題以至於需要這個變更——你可能是對的。請將解釋放在程式碼的註解中，這樣人們在看到程式碼時就能看到它。一個這樣的解釋範例是：「這個函數以前是迭代的，但當 MUMBLE 是一個樹狀結構時就失敗了。」（儘管如此簡單的原因不需要這種解釋。）
其他種類的變更解釋的最佳位置是在變更日誌條目中。特別是，註解通常不會說明為什麼某些程式碼被刪除或移動到另一個位置——這屬於執行該操作的變更的描述。
在自由文字的變更描述之後，最好根據實體或定義所在的檔案，列出你變更的實體或定義的名稱，以及每個檔案中的變更內容。請參閱 變更日誌的風格。如果專案使用現代 VCS 來保存變更日誌資訊，如 變更日誌 中所述，則明確列出已變更的檔案和函數並非絕對必要，在某些情況下（例如在許多地方進行相同的機械式變更）甚至很繁瑣。是否允許專案開發人員從日誌條目中省略已變更的檔案和函數列表，以及是否允許在某些特定條件下省略，由你決定。但是，在做出此決定時，請考慮每次變更都提供已變更實體列表的以下好處：
由於這些原因，每次變更都提供修改過的檔案和函數列表，可以使變更日誌更有用，因此我們建議在可能和實際的情況下都包含它們。
也可以透過執行腳本來產生列出修改過的實體名稱的列表。其中一個腳本是 mklog.py（用 Python 3 編寫）；它被 GCC 專案使用。Gnulib 提供了另一個此類腳本的變體，稱為 vcs-to-changelog.py，它是 vcs-to-changelog 模組的一部分。請注意，這些腳本目前支援的程式語言比 Emacs 提供的手動指令少（請參閱 變更日誌的風格）。因此，上述從 VCS 提交歷史記錄產生 ChangeLog 檔案的方法，例如透過 gitlog-to-changelog 腳本，通常會產生更好的結果——前提是貢獻者堅持提供良好的提交訊息。