有的时候我们可能会一下子往暂存区里放很多的内容,给大家举一个非常实际的例子
通常来说,比如说我们要开发一个版本,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 设置选择非模式提交
提交的时候可以选择哪个提交,哪个不提交