git.md

[TOC]

GIT 使用规范

前言

规范

[建议] master 分支仅用来发布新版本，不允许在上面开发

使用分支能够有效地避免不同开发工作之间的相关干扰。

当需要开发新功能、修复bug、试验新的想法时，应该新建一个分支，待开发工作完成并测试后，再把工作分区合并到主分区上。

[强制] 提交时须带上清晰的描述

提交信息格式：

第一行：一句话简单总结一下你做的修改（别超过50个字）
第二行：空行（必须空行）
剩余行：详细描述。为什么要做这次改动？跟以前的实现有什么不一样？

[建议] 相关的改动才放在一起提交

一次提交（git commit）应该只包含相关的改动。比如说，修复两个不同的bug就应该分开来做两次提交。提交的改动越小（或越少），其他开发者理解起来就越容易；如果改动有问题，退回去也比较方便。Git有一个暂存区域（staging area）的概念，它还允许你暂存文件的某些部分，这更便于你创建非常细粒度的提交。

[建议] 经常性地提交

经常提交势必让你每次提交的东西都很少，也有助于你只提交相关的改动。并且，你还能更频繁地与别人共享代码。通过这种方式，所有人在集成代码时都会感觉更轻松，也就能避免一些不必要的冲突。相比之下，如果每次提交的东西很多、改动很大、时间间隔很长，那么在代码合并（merge）过程中产生的冲突就很难解决了。

[建议] 高频率、细粒度地提交

把大功能的实现尽可能分解成更多的相对独立的小模块，每个小模块测试完成后提交修改，再开始下一模块的开发。

这样做能保证每次提交的内容高度相关，方便定为错误、解决合并冲突。

[建议] 提交之前进行测试

提交之前进行测试，测试完成并且没有错误才提交。

但当你把代码推送（git push）到服务器与别人共享时，这个问题就大了——在这之前，请务必测试你的代码！