有的时候我们可能会一下子往暂存区里放很多的内容，给大家举一个非常实际的例子
通常来说，比如说我们要开发一个版本，v1.0，拆分成多个模块，每个模块有多个功能。如果你手下有几个弟兄的话，一般是怎么拆分任务呢？每个人分配一个或者多个模块，这个模块中的多个功能就由那个哥儿们去负责开发。
在做项目管理，每周都是要做项目管理周报的，列出来每个人负责的内容还有时间排期，进度，风险预案，下周计划。我们都是将开发任务细化到每天的，比如下面的这个表格
那么如果在未来微服务架构那块要讲解的持续集成环境下，其实是要求每个研发人员，每天都要将这一天开发好的内容完成单元测试之后就提交，先进行代码的持续集成，然后触发一次自动化的单元测试以及持续集成测试
当然都是玩儿的持续集成+敏捷开发+自动化测试，效率
所以规范化要求，都是每天开发好的代码就提交一次，作为一个commit的
此时就有一个问题了
如果某天张三家里到下午3点的时候有事儿，孩子发烧了，39度了。老婆说，赶紧回来，人有三急，人有N急。着急忙慌往家里赶，忘了提交今天写好的那个部门管理的功能，然后第二天过来接着继续写代码，写好了另外一个员工管理的功能，然后一下子git add --all .，将昨天和今天写好的代码一起都放入暂存区，然后一次性来一个酣畅淋漓的git commit+git push，就完事儿了
此时。。。
张三突然想到，不对啊，怎么一下子要提交这么多代码，一语惊醒梦中人！！！
在规范化的，高效率的项目管理中，排期是细化到每天的，每天都要完成一定的功能或者模块，每天写好的都是一块完整的可以运行单元测试的代码，develop分支，GitFlow工作流
好像应该将这批代码分成两次提交，才能符号公司的规范啊！每天写好的功能，就一个commit！
为什么要这么干？因为公司里面代码的commit历史是很重要的，后续的话呢如果说线上有bug，需要定位bug的责任人！！！这个时候是需要用git对代码进行二分查找，找到那个bug是谁造成的！！
commit历史，漂亮而且清晰的，可以让每个人在任何时候都看的很清楚，整个项目代码的变迁
想象一下，如果每个人基本都按照公司的规范，99%的情况，其实最后公司的项目的commit历史是很漂亮的，很有价值。基本你可以看到每个人每天都干了什么？还得结合一套规范的commit提交备注，今天开发了什么什么模块。
形成今天的这一套复杂的系统的
我现在给大家讲解的，很多我不知道大家之前有没有这些概念，但是这都是一个规范的大公司里的大项目的要做的事情，BAT，规范是很严格
符合规范，才能让项目的质量更高，更好
中小型的公司里面工作，可能没有对这些那么的注意，那么此时我也建议大家都好好听听这些工作里的实践经验，大公司里的工作方法和规范
如果你以后去大公司面试通过，去工作，你会觉得大公司的规范，让你感觉似曾相识，而且我后面的话，在整个做项目的过程中，都会给大家引入很多我多年在大公司里工作，做核心项目积累的经验，项目管控上经验
要让你的兄弟们去遵守的
或者如果你把这一套经验和规范吸收了，学会了，那么以后你如果去一个小公司里R一个大项目，架构师，带一群小弟，就可以把这些经验和规范应用到小公司里去，小公司也可以做的高大上一点儿，规范一点，标准化一点，漂亮一点儿
这个时候就要用下面的高阶实战技巧了，假设你不小心将多天的代码都提交到了暂存区里面去，此时可以将暂存区里的内容分成多个commit来提交
此时需要先执行一个命令，进入交互式模式：git add -i
这个时候会给你列出来当前暂存区里所有的文件和内容，以及没加入暂存区的文件和内容
还有一堆可以执行命令
此时张三写好的那些代码都被之前的git add --all .放入了暂存区，还好还好，我们可以搞一搞，恢复一下
此时根据各种指令以及选择文件，将暂存区中的员工管理功能对应的文件和代码，先unstage出来，从暂存区里挪出来
2：update是放入暂存区，3：revert是从暂存区里挪出来
通过这个技巧，就可以将暂存区里部分文件给挪出来，然后再执行commit操作，将代码分成多次来提交，每天写好的功能是一个commit，跟公司的规范保持统一
通过刚才演示的这个技巧，一旦你不小心将多天的代码都放入了暂存区，可以通过git add -i进入一个交互模式，然后选择将部分文件从暂存区里挪出来
idea 设置选择非模式提交
提交的时候可以选择哪个提交,哪个不提交