Git 使用的一些命令以及Git commit 注释格式

撒的阿坎努斯

1、Git 快速教程及命令　　

　　流程： 取代码 → 每次工作前更新代码到最新版本 → 修改代码 → 提交代码到服务器
　　1. 取代码及修改全局设置
　　a. 设置用户名与邮箱
　　

git config --global user.name "My Name"　　
git config --global user.email "my@email.com"
　　

　　

　　b. 从已有的git库中提取代码
　　

git clone git@server:app .git myrepo　　

　　

　　2. 每次更改代码的操作
　　a. 更新本地代码到最新版本（需要merge才能合到本地代码中）
　　

git fetch　　

　　

　　b. 合并更新后的代码到本地
　　

git merge　　

　　

　　c. 更新代码方式的另一种方法(git pull是git fetch和git merge命令的一个组合)
　　

git pull　　

　　

　　d. 修改代码后，查看已修改的内容
　　

git diff --cached　　

　　

　　e. 将新增加文件加入到git中
　　

git add file1 file2 file3　　

　　

　　f. 从Git中删除文件
　　

git rm file1　　
git rm -r dir1
　　

　　

　　g. 提交修改
　　

git commit -m 'this is memo'　　

　　

　　如果想省掉提交之前的 git add 命令，可以直接用
　　

git commit -a -m 'this is memo'　　

　　

　　commit和commit -a的区别, commit -a相当于：

• 第一步：自动地add所有改动的代码，使得所有的开发代码都列于index file中
  
• 第二步：自动地删除那些在index file中但不在工作树中的文件
  
• 第三步：执行commit命令来提交
  

　　h. 提交所有修改到远程服务器，这样，其它团队成员才能更新到这些修改
　　

git push　　

　　

　　3. 附注
　　遇到过的一些错误：
　　Git – fatal: Unable to create ‘/path/my_project/.git/index.lock’: File exists.

　　fatal: Unable to create ‘/path/my_proj/.git/index.lock’: File exists.
　　If no other git process is currently running, this probably means a
　　git process crashed in this repository earlier. Make sure no other git
　　process is running and remove the file manually to continue.

　　可以试着删除 index.lock
　　

rm -f ./.git/index.lock　　2、Git commit 注释格式
　　

　　Git 本身并没有硬性限制注释的格式，不过，对于多人参与的项目来说， 好的注释风格更加有利于团队合作。 即使是自己用，也应当坚持实用好的注释风格， 一来是对自己的工作历史负责，二来得以养成好的注释习惯。 虽然这里标题说的是 Git，其他源代码控制系统也可以参考的。
　　可以先看看一些著名开源项目源代码管理系统当中的提交注释， 其中也有用 SVN 和 Bazaar 的， Apahe 的源码看不到 logview，可能是使用了 CVS 文件格式的原因：

• Linux Kernel
  
• Apache HTTPD
  
• Mysql Server 5.6
  
• PHP
  
• Git
  

　　结合其他参考文章，我总结 Git 的 推荐 注释风格如下：

• 　　第一行为对改动的简要总结，建议长度不超过 50，用语采用命令式而非过去式。
  　　Vim 很贴心，在默认配置下，注释的第一行文字颜色是黄色， 超过 50 列之后就变成白色了。
  
  
• 　　第一行结尾不要英文的句号 . ，中文的就也不要 。 吧。
  　　为啥？我给 rst2wp 提交的时候，对方也提出了这个要求 [1] [2] ， 后来查了查，大概原因是，第一行被认为是一个“标题”，也会作为邮件标题， 而标题是不需要标点的。 上面那些开源项目也都遵守了这一规则。 不过也有 例外的 。
  
  
• 　　第二行为空行。
  　　如果配置了自动发送邮件，那么第一行就用来做邮件标题， 第三行开始的内容是邮件正文， 第二行是分隔线，用于区分两者。
  
  
• 　　第三行开始，是对改动的详细介绍，可以是多行内容，建议每行长度不超过 72。
  　　可以包括原因、做法、效果等很多内容，一切你认为与当前改动相关的。 为何是 72 长度呢？因为 git log 输出的时候能显示得比较好看， 前面 4 个空格作为缩进，后面留 4 个空格机动（英文按单词排版）。 Vim 的 gq 命令排版很方便。
  　　一些项目还对这个部分的内容有特殊要求，比如加一些特定标签什么的。
  
  
• 　　建议全部英文，首字母大写。如果一定要用中文，请尽量使用 UTF-8 编码。
  
  
• 　　大项目中，可以用 module/submodule: 前缀作为第一行的开头， 前缀首字母不必大写。
  　　前缀的冒号后面跟一个空格比较好看。 为了控制字符串长度，子模块名称可适当缩写，但应保持统一。
  
  

　　我以前喜欢在注释第一行加上 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”、“改错”、“升级”等，没有其他内容，等于没说。
  
  

参考

• Pro Git – 5.2 Contributing to a Project – Commit Guidelines
  
• A Note About Git Commit Messages
  
• Git Commit Messages : 50/72 Formatting
  
• Writing good commit messages
  
• How to wrap git commit comments?
  
• [git/git.git] / Documentation / SubmittingPatches
  
• Shiny new commit styles
  
• Who-T: On commit messages
  
• Commit Comments – Whamcloud Community
  
• How I Use Git
  
• http://whatthecommit.com/ （要多刷新几次页面，仔细看）