1、觸發事件
我有這樣一個版本庫，里面包含兩個學習用的練習項目：BookStore（以下簡稱BS）和PictureFriend（以下簡稱PF）
我在更改PF以后，未進行提交，同時又到BS中優化了一下文件夾結構，然后此時我commit，提交備注信息為“
添加圖友網項目，更改為Maven形式，報錯找不到spring監聽器，待解決”，提交成功，似乎沒什么問題。
但是當我在github上看到的情況如下，我知道我沒有處理好：
BookStore項目實際上跟這個備注並沒有關系，而是PictureFriend才主要是這次commit的內容，只是因為我將兩個項目的操作在同一次commit中進行提交，造成了這樣的情況。可見如果是正式的項目，如此的提交是多么混亂，他人將難以維護和修改。
究其原因，主要還是在
正確的git提交姿勢上知之甚少：
1、不同的要分別分次提交，（這里不同指 如：不同的修改類型//優化還是新增etc.//，不同的模塊，不同的功能等）；
2、提交的信息要進行一定程度的格式化。
2、知之為知之
commit的寫法規范有很多，以下參考網絡相關文章，並進行簡化以定義個人風格。
參考鏈接：
2.1 Commit message的格式化
每次提交，Commit message 都包括兩個核心部分：
標題 和
內容。
<類型>(可選): <主題>
// 空一行
<內容>
3
1
<類型>(可選): <主題>
2
// 空一行
3
<內容>
其中，
標題 是必需的，內容無需過多描述的話，正文內容部分可以省略。
不管是哪一個部分，任何一行都不得超過72個字符（或100個字符）。這是為了避免自動換行影響美觀。
2.1.1 標題
標題部分只有一行，包括字段：
類型 和
主題。
標題限制總字數在50個字符以內，以保證容易閱讀。
e.g.
feat: init LearnGit.git
I got a wrong-style git commit, so I init a .git for learning
how to write a git commit message in right way.
And the last line just write here for a simple test,
it's useless acturally.
x
1
feat: init LearnGit.git
2
3
I got a wrong-style git commit, so I init a .git for learning
4
how to write a git commit message in right way.
5
6
And the last line just write here for a simple test,
7
it's useless acturally.
2.1.1.1 類型
類型 用於說明 commit 的類別，只允許使用下面7個標識。
- init：項目初始化（用於項目初始化或其他某種行為的開始描述，不影響代碼）
- feat：新功能（feature）
- fix：修補bug
- docs：文檔（documentation）
- opt：優化和改善，比如彈窗進行確認提示等相關的，不會改動邏輯和具體功能等
- style： 格式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：增加測試
- save：單純地保存記錄
- other：用於難以分類的類別（不建議使用，但一些如刪除不必要的文件，更新.ignore之類的可以使用）
（可選）類型后面可以加上括號，括號內填寫主要變動的范圍，比如按功能模塊分，某模塊；或按項目三層架構模式分，分數據層、控制層之類的。
- #：表示模塊
- #student --> 表示 學生模塊 （具體的模塊開頭字母小寫，駝峰命名）
- #ALL --> 表示 所有模塊 （特殊含義如ALL表所有，MOST表大部分，用大寫字母表示）
- #MOST --> 表示 大部分模塊
e.g. feat(#student): 新增添加學生的功能 —— 表示student模塊新增功能，功能是添加學生
2.1.1.2 主題
主題 是 commit 目的的簡短描述，不超過50個字符。
- 以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
- 第一個字母小寫
- 結尾不加句號（.）
2.1.2 內容
內容部分是對本次 commit 的詳細描述，可以分成多行，正文在 72 個字符處換行。
使用正文解釋是什么(what)和為什么(why)，而不是如何做，以及與以前行為的對比。
於是可以這樣寫：
balabala : balabala
what:
balabala
why:
balabala
2.2 格式化后Commit message的好處
2.2.1 提供更多的歷史信息，方便快速瀏覽
直接使用git log你得到的是：
比如，下面的命令顯示上次發布后的變動，每個commit占據一行。你只看行首，就知道某次 commit 的目的。
$ git log <last tag> HEAD --pretty=format:%s
1
1
$ git log <last tag> HEAD --pretty=format:%s
關於更多git log的輸出格式，參考以下：
2.2.2 可以過濾某些commit（比如文檔改動），便於快速查找信息
比如，下面的命令僅僅顯示feat類型的commit。
$ git log <last release> HEAD --grep feat
1
$ git log <last release> HEAD --grep feat
當然，你還可以這樣：
關於更多過濾規則，參考以下：
e.g.
