假如我开发一个软件需要用到git来管理，这个软件有很多的功能模块，请问：
1、每实现一个功能功能就只commit一次吗？
2、只要觉得有commit的必要就commit，比如修改个小bug，然后commit
我是新手，每次提交修改的文件都很多，很乱，有些修改还是和这次commit无关的文件。
请问各位是怎么做的呢？ 谢谢。
即使只是加了一行代码，也可一作为一个 commit。
无关的代码不要提交到本次 commit。
你要知道你要达到的效果是，如果有一天我要你回滚到某个历史状态，你能很快的找到那次提交并回滚。如果做不到这一点，你怎么 commit 都无所谓了。
比如某一次你将一个默认值由50改为100，那么，这就应该作为一次提交。如果你顺手修了一个 bug，也不能放在这次提交里，要不然要怎么回滚到 50 呢？难道你回滚了之后还要重新修复那个 bug 吗？
你不知道怎么提交是因为你没有一个确定的目的。
我是这么认为的。
可以参考下git flow 我觉得可以从大的点上解决你的疑惑
http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html
一般会有这么几种分支 master develop 各种feature分支 bug_fix分支 hot_fix分支
master一般是正式线上版，develop不用说，开发的，不过放在develop里面的也已经是相对稳定的分支，而你要开发新的特性的时候，确保你在develop分支上新建一条feature_XXX分支，各种commit commit commit,
如果后期发现之前的版本有某个bug，不影响线上的会建立一条bug_fix_XXX分支，而影响线上的严重bug则新建hot_fix分支，hot_fix与bug_fix不同，解决bug后会将hot_fix分支merge到master注意是master。
另外，如果你想保持你分支整洁干净，你可能需要用到rebase来合并代码，而不是merge
git的玩意儿推荐看下progit吧，非常之全面。
我一般是
- 分支 branch
- commit、commit、commit、commit ……
- 修复了一个bug、或解决了一个问题 merge
- commit、commit、commit、commit …… merge
- pull
多用rebase，少用merge
这个随意啊,主要还是为了以后自己或是别人看起来方便,能知道你commit的信息代码里改了那些,,,,与功能无关的页面commit 信息里我也会说清楚的。反正勤于commit的吧,一个功能提交一次肯定不够的
要很详细的话，就只能一个具体的功能地提交了。
不过好费事儿啊。
另外，也可以使用git gui 中文提交，描述清楚点。