针对程序员来说，git是一个绕不开的工具，只要涉及到工程版本迭代，就必然涉及到历史版本的管理，如果没有遇到特殊的情况，它的三板斧足够解决问题，所谓三板斧其实是三条命令:
git add ./
git commit -m "xxx"
git push (orgin master)
git add命令把本地所有untrack的文件都加入暂存区，据别的网页描述， git add * 和 git add .的区别是会不会过滤掉.gitignore文件， git add . 不会提交此文件， 如果是明确的某文件修改， 可以直接git add xxx(filename)。
git commit命令将暂存区内容添加到本地仓库中， -m 后面写一些修改部分描述，方便之后回溯和查看，如果感觉git add 太麻烦， 可以将git add 和git commit 合二为一， 即 git commit -a -m "xxx"。
git push命令用于从将本地的分支版本上传到远程并合并, 括号内非必须， 如果是有分支，需指定提交分支。
如果要使代码提交每次更加规范，主要要注意的地方是把每次的变动详尽描述清楚，这也是本文的一个主要目的， 即 git commit -m "xxx"的 message应该怎样规范化编写，纯属个人根据网上信息汇总和提炼，如有不到之处，还望不吝赐教。
message 主要的一个格式是<type><scope>: <subject><body><footer>，对于大部分提交来说，没必要这么复杂，只需要保留type(scope): 描述(#issue)，scope即修改的文件，描述即具体的修改细节。type实际的定义有9类之多，下面我罗列一些最常用到的几类：
1、build：构建项目，可用于第一git工程生成的提交信息，表示搭建了一个项目，有些也说用init，具体也没查到他们的详尽描述；
2、fix：修复bug，不言自明，修复了代码错误时使用；
3、feat：新特性，增加新功能；
4、refractor：代码重构，即不是新增功能，也不是修改bug的代码变动；
5、docs：文档， 不涉及代码修改，修改了配置文件或者说明文档；
6、test：测试， 关于测试方面所有的修改均可用它；
7、style： 格式（不影响代码运行的变动），用的可能性不大。
综上描述，最常用的几种类型为fix、feat和refractor，最最常用必然是fix，毕竟程序员都是bug制造机。以此为例，提供一个之前写的供参考：
fix(scholar/utils/format.py)： 修改出参includeCriterion字段的类型，由字符串统一为列表
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
