Git

标签：

和源码无关的东西，尽量不要进仓库

不得不说一些图形化软件，在提交内容的时候大多提供一个“全选”或者“Select All”功能，这是最不好的了，一些懒惰的同志看都不看就连瓢带碗都提交了。

• 测试时上传的文件，测试时的临时文件，统统不要
• 对应上一条，强烈建议把所有文件的上传保存目录另行设置，放到源代码目录以外
• 编辑器产生的备份文件、临时文件，编译时的中间文件，统统不要
• 对应上一条，有个例外就是为了实现通过 Git 更新系统，.NET 的 bin 文件要进仓库，导致那个仓库现在都 100+m 了
• 图片等资源文件，进仓库也可以，但应当使用有意义的文件名，便于后期管理
• 对应上一条，现在设计网站界面喜欢先作图然后切割，产生一大堆 001_r5_c1.jpg 这样的文件，讨厌之极
• 使用的外部类库，比如 php 类、js 类等，统统扔到源码目录以外，如果实在没办法要放在目录树中，也可以留出空目录，打包发行的时候再包含进来，依然不进代码仓库
• 不要中文文件名，主要是跨平台使用有问题，文件名完全能够只用字母数字减号下划线

尽量采用相对小、相对独立的提交

Git 是作什么用的？Git 不是代码上传工具，也不是网站更新工具，而是软件开发过程的记录工具，为了更加准确的定位每个问题、每个功能修改，就需要在每完成一部分可以称得上是“一项”的工作时，就 commit 一次。哪怕只是修改了一两行，只要产生了必要的功能改变，就有价值记录。

当采用代码审核机制或者需要用邮件提交补丁时，较小的提交能够更有效、更容易、更准确的被检查和审核，这个在 linux kernel 开发文档中也有提到。

当然不能矫枉过正，必须有可记录的改变才有提交的价值。对应的，Git 日志大多数情况下主要显示第一行，控制每次提交都能用一句话简单概括，也是有必要的。

注释格式

格式属于个人习惯和团队规范范围，有必要采用相对统一的风格。

Git 本身不允许空注释，同时建议注释的第一行写简要说明，下面留一行空行，再写详细说明。

我的个人习惯，喜欢在每条注释前面用大约三个字母来表示本次修改的性质：

• Add something
• Bug [fix|found]: describe the bug or fix.
• Chg something
• Del something
• Enh some treatment
• New something
• Tmp for some cause

为了保持语法通顺，也可以采用前三个字母后面加冒号，后面有啥写啥的方法。

最后，我觉得，能够遵守行业规范和团队约定，主动养成良好习惯，应当是鉴别人才的一项重要因素。

Update @ 2012-12-03

关于注释格式，在使用了几年 Git 后，又有了更深的认识， 参见 Git commit 注释格式。

Git 本身并没有硬性限制注释的格式，不过，对于多人参与的项目来说， 好的注释风格更加有利于团队合作。 即使是自己用，也应当坚持实用好的注释风格， 一来是对自己的工作历史负责，二来得以养成好的注释习惯。 虽然这里标题说的是 Git，其他源代码控制系统也可以参考的。

可以先看看一些著名开源项目源代码管理系统当中的提交注释， 其中也有用 SVN 和 Bazaar 的， Apahe 的源码看不到 logview，可能是使用了 CVS 文件格式的原因：

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

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

1. 第一行为对改动的简要总结，建议长度不超过 50，用语采用命令式而非过去式。

   Vim 很贴心，在默认配置下，注释的第一行文字颜色是黄色， 超过 50 列之后就变成白色了。

2. 第一行结尾不要英文的句号 . ，中文的就也不要 。 吧。

   为啥？我给 rst2wp 提交的时候，对方也提出了这个要求 [1] [2] ， 后来查了查，大概原因是，第一行被认为是一个“标题”，也会作为邮件标题， 而标题是不需要标点的。 上面那些开源项目也都遵守了这一规则。 不过也有 例外的 。

3. 第二行为空行。

   如果配置了自动发送邮件，那么第一行就用来做邮件标题， 第三行开始的内容是邮件正文， 第二行是分隔线，用于区分两者。

4. 第三行开始，是对改动的详细介绍，可以是多行内容，建议每行长度不超过 72。

   可以包括原因、做法、效果等很多内容，一切你认为与当前改动相关的。 为何是 72 长度呢？因为 git log 输出的时候能显示得比较好看， 前面 4 个空格作为缩进，后面留 4 个空格机动（英文按单词排版）。 Vim 的 gq 命令排版很方便。

   一些项目还对这个部分的内容有特殊要求，比如加一些特定标签什么的。

5. 建议全部英文，首字母大写。如果一定要用中文，请尽量使用 UTF-8 编码。

6. 大项目中，可以用 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”、“改错”、“升级”等，没有其他内容，等于没说。

Git

标签：

原文地址：http://www.cnblogs.com/tonny-li/p/4225724.html