git修改commit的備注信息? Git 本身并沒有硬性限制注釋的格式，不過，對于多人參與的項目來說， 好的注釋風格更加有利于團隊合作 即使是自己用，也應當堅持實用好的注釋風格， 一來是對自己的工作曆史負責，二來得以養成好的注釋習慣 雖然這裡标題說的是 Git，其他源代碼控制系統也可以參考的，我來為大家科普一下關于git修改commit的備注信息?下面希望有你要的答案，我們一起來看看吧!

git修改commit的備注信息

Git 本身并沒有硬性限制注釋的格式，不過，對于多人參與的項目來說， 好的注釋風格更加有利于團隊合作。 即使是自己用，也應當堅持實用好的注釋風格， 一來是對自己的工作曆史負責，二來得以養成好的注釋習慣。 雖然這裡标題說的是 Git，其他源代碼控制系統也可以參考的。

可以先看看一些著名開源項目源代碼管理系統當中的提交注釋， 其中也有用 SVN 和 Bazaar 的， Apahe 的源碼看不到 logview，可能是使用了 CVS 文件格式的原因：

• 結合其他參考文章，我總結 Git 的 推薦 注釋風格如下：
• 第一行為對改動的簡要總結，建議長度不超過 50，用語采用命令式而非過去式。
• Vim 很貼心，在默認配置下，注釋的第一行文字顔色是黃色， 超過 50 列之後就變成白色了。
• 第一行結尾不要英文的句号 . ，中文的就也不要 。 吧。
• 為啥？我給 rst2wp 提交的時候，對方也提出了這個要求， 後來查了查，大概原因是，第一行被認為是一個“标題”，也會作為郵件标題， 而标題是不需要标點的。 上面那些開源項目也都遵守了這一規則。 不過也有 例外的 。
• 第二行為空行。
• 如果配置了自動發送郵件，那麼第一行就用來做郵件标題， 第三行開始的内容是郵件正文， 第二行是分隔線，用于區分兩者。
• 第三行開始，是對改動的詳細介紹，可以是多行内容，建議長度不超過 72。
• 可以包括原因、做法、效果等很多内容，一切你認為與當前改動相關的。 為何是 72 長度呢？因為 git log 輸出的時候能顯示得比較好看， 前面 4 個空格作為縮進，後面留 4 個空格機動(英文按單詞排版)。 Vim 的 gq 命令排版很方便。
• 一些項目還對這個部分的内容有特殊要求，比如加一些特定标簽什麼的。
• 建議全部英文，首字母大寫。如果一定要用中文，請盡量使用 UTF-8 編碼。
• 大項目中，可以用 module: 前綴作為第一行的開頭，前綴首字母不必大寫。
• 前綴的冒号後面跟一個空格比較好看。 為了控制字符串長度，子模塊名稱可适當縮寫，但應保持統一。
• 我以前喜歡在注釋第一行加上 New: Add: Fix: 這樣的前綴， 看來也是沒有必要了。
• Tips: 提交之前，用 git diff --check 可以檢查有無空白字符錯誤， 比如行尾留有空白什麼的。
• BTW，在使用 Git 或者其他 SCM 時，還應當避免下面這些做法：
• 把 SCM 當做備份工具。
• SCM 是項目/代碼管理工具，備份功能隻是“福利”。 随意将未完成測試或臨時的工作結果進行提交， 不僅破壞日志的“純潔性”，還不利于日後的浏覽、整理、彙總等工作。 在開源項目中這麼做的話，沒人會接受這種提交。 如果确實需要備份當前工作異地繼續的話，可以采用這樣的折衷方法：

$ git commit # 在本地進行提交 $ git format-patch -n1 # 導出 Patch # 這個 Patch 就是你的備份 $ git am Path_To_Patch_File # 如果換了工作地點，導入 Patch $ git reset --mixed [hash] # 撤銷提交，保留更改，繼續工作

• 一個改動不一次提交完成。
• “提交”的概念是具有獨立的功能、修正等作用。 小可以小到隻修改一行，大可以到改動很多文件， 但劃分的标準不變，一個提交就是解決一個問題的。
• 對格式的修正，不應該和其他功能修補一起提交， 這種情況應該考慮使用 git add --edit ， git add -p 也可以用用，更複雜和強大一些。
• 注釋不清晰。
• 比如“修正 BUG”、“改錯”、“升級”等，等于沒說。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!