如何寫好 Git commit log?
目前我傾向於以下的風格，期望大家能給出更好的建議或使用經驗。
主要功能描述：
* 細節1
* 細節2
* 細節3在爆棧上也有類似的討論，請參見
Git Commit Messages : 50/72 Formatting基本上我很同意50/72的書寫方式，當然我也更同意寫得亂七八糟比什麼都不寫要好。好像這個問題沒什麼人想討論，是因為國內用Git的人還是少嗎？
可以在 git commit 的時候使用 Emoji 為每次提交打上一個標籤。使得每次 commit 獨具一格，鶴立雞群，在整個提交歷史長流中很容易找到。說實話，這樣子不僅覺得自己看起來很呆萌，更重要的是 Emoji 表情包含的豐富的語義和情緒，使得提交記錄非常好理解，閱讀體驗非常棒，如下圖。
使用 Emoji 當做標籤，能非常好的對提交記錄分門別類進行整理，你看
? Add feature 1
? Add feature 2
? Add feature 3
對於這類型記錄，一看就知道添加了一些新 feature 進來了。
Add colors for new gitmojis
Add boom gitmoji styles
Update emojis order, add mising colors
哎，知乎回答對 emoji 支持不是很好，好多都不能正常顯示，建議到這篇文章看看完整的，https://zhuanlan.zhihu.com/p/29764863
對於這些記錄，主要是樣式方面的調整 。
Update yarn.lock package.json
Update .travis.yml
對於這些呢，是修改配置文件。
Update flexboxgrid
Import clipboard only when needed
這些，哪個豬隊友又在寫 Bug 啊！
?? improve performance of card hover effect
這裡進行了一次性能優化，速度像閃電一樣快。
那麼這些 Emoji 是怎麼使用？答案是，在 Emoji 的名字前後個加上一個冒號:name_of_emoji:
因此，我們可以這樣提交代碼
git commit -m " fix a bug writtten by pig teammate"
他的效果是這樣的：
fix a bug written by pig teammate
但是這些 Emoji 標籤不能亂用，必須統一規範，不然很容易造成誤解，https://gitmoji.carloscuesta.me/ （可以點擊原文鏈接查看）整理了一套規範。大家可以保存，以備參考。
我們不僅可以在 git commit 時，在 README.md，在 git wiki 裡面都可以直接使用 Emoji，是不是很有意思。
以上，funny it！
我看過的比較合理的是 thoughtbot 的規範：
dotfiles/gitmessage at master · thoughtbot/dotfiles · GitHub
# 50-character subject line
#
# 72-character wrapped longer description. This should answer:
#
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# Include a link to the ticket, if any.
他們有寫一篇文章解釋：
5 Useful Tips For A Better Commit Message
另外，大家可以看看 Linux 的 Commit Message 是怎麼寫的, 基本上都是長篇大論的：
Commits · torvalds/linux · GitHub
Linus 也討論過此事： https://github.com/torvalds/linux/pull/17#issuecomment-5659933
這種東西，當然要藉助工具了，才能夠寫得即規範，又格式化，還能夠支持後續分析。
目前比較建議的是，使用終端工具 commitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-version 一步解決提交信息和版本發布。
甚至，如果想更狠一點，在持續集成裡面加入 marionebl/commitlint 檢查 commit 信息是否符合規範，也不是不可以。
git commit -m"`curl -s http://whatthecommit.com/index.txt`"
隨機生成commit message
不說了，上當年的截圖
到最後 @Guanlun 終於沒法忍了……，於是：
我是GitHub新人，覺得commit可以簡短，在Pull Request才慢慢寫清楚一堆commits的整體沿由及方案。
堅持使用顏文字 _(:3 」∠)_
like this:
把關鍵字寫上，帶點短小的description就可以了。或者如果你遵守軟體工程的做法，產品狗和測試給你開workitem或者bug的話，把id寫上，這樣的話description已經寫在workitem和bug裡面了你不用寫了。太多廢話只會讓人難受。
我用這個：
Writing good commit messages · erlang/otp Wiki · GitHub
Qt Project的commit message模版：
# ==[ Subject: One line only short meaningful description for logs ]===|
# ==[ Details: Describe what changed and explain why it changed ]======|
# Change log entry (see below for instructions).
#[ChangeLog][][]
# ==[ Footers: Uncomment and edit where applicable ]===================|
#
# One task per entry. Remember space after colon.
#Task-number:
#Coverity-Id:
#
# ==[ Please wrap at 72 characters ]===================================|
#
# Remember to read http://wiki.qt.io/Commit_Policy
#
# Change log entry: If this commit adds a significant feature, fixes an
# issue or contains a behavior change that is relevant to others,
# add a change log entry. It can be multiple lines long and ends with an
# empty newline. Try to integrate it into the flow of the commit message
# to avoid redundancy.
# Use the module name to indicate the area of the change e.g. [QtCore].
# Optionally specify a class or subtopic [QtNetwork][QSslSocket].
# Other common tags are: [General], [Important Behavior Changes],
# [Platform Specific Changes][Windows][OS X][Linux/XCB].
#
# [ChangeLog][module][class/topic] description of the really important
# change that was just made on several lines.
https://github.com/qt/qt5/blob/5.9/.commit-template
Commit Policy - Qt Wiki
我覺得沒有任何比 Linux 社區的人更會使用 git commit 的人了。畢竟 git 一開始就是為了 kernel 發明的。
mdss: switch color mode in one node
Instead of having separated nodes of SRGB, Adobe_RGB and DCI_P3, we now
merge them into one node: /sys/class/graphics/fb0/color_profile
0 - no color profile
1 - sRGB
2 - Adobe RGB
3 - DCI-P3
Change-Id: Icd538e0b7f7903f047f6cb773cbee14fc7525027
其實說 Linux 社區也不完全準確。實際上上面這段是我給 MoKee 上一加5的內核提交，大致習慣還是和 Linux 本身兼容的。
第一行，標題，控制在 80 字以內。這會作為這一個 Patch 的標題，出現在郵件列表裡，出現在 Review 系統里（MoKee 等 AOSP 項目就是 Gerrit https://review.mfunz.com/ ）
空一行，畢竟這是兼容 Markdown 的對不。
開始闡述你這個修改的目的，同樣控制在一行 80 個字元內（手動換行）。
Change-Id 是我們 Gerrit 使用 pre-commit hook 自動生成插入的。
修改 ~/.gitmsg
我的模板大概這樣：
Title:
Description:
一個好的 git commit message 的標準可能不唯一，但是和注釋一樣的訴求，讓閱讀它們的人看得更清楚，更輕鬆。
所以一個壞的 message 大概是這樣的：描述很長，描述模糊。
描述很長：
有人問我，怎樣讓構造函數有一個返回值？怎樣讓普通函數有超過一個的返回值？我想答案大概是，如果想在一句話裡面包含過多信息，那麼這個想法本身就不合理。 就一個 commit 而言，可以是一個特性（開發分支），可以是一個 bugfix，甚至可以 --allow-empty，就是不能包含無法拆分，不好拆分的東西，簡單說就是不能太多太複雜。原因是 git 精髓是分支管理，而分支管理的元素就是 commit，如果一個 commit 包含兩個特性，就無法就其中某一個特性進行 cherry-pick，git 的作用就無法發揮。
同樣的，對於閱讀者，message 的作用是用於查閱，通常的使用場景時 git log --oneline 或者 gitk --all，這時在閱讀者眼前可能是幾十條 commit，當看到某一條 commit message 時，90%不是為了讀懂這條 commit 是什麼，而是確認它不是什麼，以快速找到自己真正想看到的。。我說的有點極端，大工程可能遇到，但是對於自己手裡的兩三個分支，言簡意賅絕對是提高幸福感的鑰匙。
描述模糊：
這些字不要出現在 commit message 中：
bugfix（如果真的需要，可以在 gitmsg 中增加一行 feature / bugfix:），
modify（包括 modi、mod、modification），
problem（。。），
some values（如果只是改參數，「參數的含義」而不是「一些參數」），
中文（no why），
temp（臨時放在這），
todo（原因待編輯），
final（不要把返工時的心情放在這裡好嗎），
Jack"s code（把 patch 甩給 Jack 讓他自己來）
同時的，請還有一些通用的約束，比如：
如果同時使用了 gerrit ，那麼 message 就更要短，不然在 gerrit 上顯示兩行，更要丑。。。
每行不要超過 80 個字元。
首字母大寫。
如果有 conflict 欄位（這個 commit 來自一個 cherry-pick 或者 rebase），描述一下衝突（此處可以詳細！不然以後會痛）。
描述 revert "commit xxxxxxx" 的原因（這個 commit 來自一個 revert）。
自從開始用 emoji，就停不下來了，比打字好使多了（大霧）
把必要的內容簡單描述下來感覺就差不多了，更詳細的內容直接diff一下就全清楚了，當然一次 commit 搞得跟天地翻轉一樣。那啥，不是還有個叫做文檔的東西么。
在Github上，如果是fix一個issue，在commit log裡面寫上類似" fix #1: blabla",
merge之後那個issue自然就關閉了，好用~~
每次一個小的改動就是一個commit,不要一大堆改動一個commit,不然review的時候痛苦到死.
這樣review起來方便 log寫起也簡單.
考慮一下git commit的本質屬性，是一個郵件格式的patch，commit log的第一行將是郵件的標題，後面的是郵件的本文，然後patch部分以diff格式附在正文最後。
因此，commit log的list其實跟收件箱是一致的，作為標題，應該明確的說明解決了什麼問題，然後，可以換行寫入更詳細的說明。修改的：[MOD] 1、*******
2、*******
添加的：[ADD] 1、*********
2、*********
BUG： [BUG] 1、**********
2、*********
刪除的：[DEL] 1、**********
2、**********
我平時commit日誌是這樣子的：
從軟體研發項目角度看：
amazon旗下Quidsi的大部分項目，對svn / git log等的管理還是覺得比較舒適的。
由於項目管理平台使用的是jira（禪道等同理），所以log 之類的只有一個標準，就是 jira任務編號+標題。
如 CO-13423 MA-2342 XXXXXXX
這樣一來，直接相當於把所有的版本變更跟 任務 掛鉤起來了，有據可查。
好處：
0）程序員再也不用思考如何去寫個log了，簡單複製無壓力
1）可追溯，只要項目管理關聯的好，甚至從概念設計、需求設計等都可追溯到，再也不用去扯淡為什麼要這樣做等等程序員不擅長的事了
2）方便別人code review，知道做什麼，為什麼要這樣做。減少頻繁的無謂溝通
3）版本提交的時候，甚至可以通過 log的格式去校驗對應的 任務單據狀態是否正確，協助做好項目管理工作。如log包含 CO12444 ，假如這個單據狀態處於不可提交（已發布等）那麼就不讓做代碼提交
0）一句話描述重點，創建一個別人簡單易懂的任務
1）做好任務管理（關聯）
2）……
其他的，等你來補充..
謝邀。
開發過程中，往往已經千辛萬苦的做完了一堆功能或修完了幾個bug，臨提交還要面臨如何描述的問題，這確實讓人撓頭。
commit log既是寫來給人看的，又是人來寫的。看了各位朋友的回答，很多說要有規範，類似文檔規範。我以為大可不必，正如Linus所說——「Talk is cheap, show me the code!"，代碼才是核心，commit log言簡意賅即可，要求那麼多複雜的規範豈不是降低了開發者的效率嘛。
commit log這種東西，如果沒問題，想必不會有人去仔細查看，而一旦出了問題，想看卻沒得看就只能幹瞪眼，唯獨只能看代碼來揣摩作者意圖了，想必這也是很痛苦的。log的文檔規範是否有必要先放在一邊，我認為一個合格的commit log要符合以下幾點：
- 不要獨樹一幟。整個團隊都在用中文提交，就不要秀自己的CET-4啦
- 言簡意賅。若是修了BUG，就說我修了什麼什麼BUG，至於為什麼有這個BUG，以後該怎麼避免，大可放在代碼中注釋上去，你放在commit里，有誰會去看呢？
- 只干一件事。其實這不是說commit log啦，意思是說一個commit應盡量原子化，不要東一個功能西一個功能的代碼放在一起提交一個commit，以後一旦出了問題回退也不好回退啊。修一個BUG、改一行文案、做一個功能，速度commit下，又不按次數要錢的
我認為的合格的commit (log)即為以上的意思吧。
咱們回過頭來說規範是否有必要的問題，如果團隊中能推行下去，當然是最為理想的，每個人提交一件事情就寫個小作文出來，對工程健康度絕對有幫助。可話又說回來了，有這個時間去多寫幾行代碼不好么？
摸著良心寫
推薦閱讀：