我们为什么要使用git
应用场景分析
1.使用svn,已经开发完一个需求,正在开发第二个需求,但是测试需要你立刻将你完成的第一个需求提交,请问现在你该怎么做:
svn的解决方法大概是这样的:打开提交视图,人为的去分辨哪些是第一个需求的文件,哪些是第二个需求的文件,然后提交第一个需求的相关文件,这种人为的
工作,第一点就是人工的工作容易出现差错,第二就是对人力的浪费
那么如果采用git,我们需要怎么做呢?
git的本地提交,有一个暂存区的概念,每次代码提交的时候提交的是暂存区的代码,你可以再做完第一个需求的,测试通过的情况下,使用命令git add file将已测试通过的代码
保存到暂存区,之后你就可以肆意的开始做第二个需求了,需要提交第一个需求的时候,git commit就ok了.(使用暂存区如果较为繁琐,可以git commit -a全部提交)
2.有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了,怎么办?
svn:
1. svn update，svn log，找到最新版本（latest revision）
2. 找到自己想要回滚的版本号（rollbak revision）
3. 用svn merge来回滚： svn merge -r : something
git:
git commit --amend,这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所
修改的只是提交信息。最终你只会有一个提交 - 第二次提交将代替第一次提交的结果。
3.基定版本已经上线(1.0),这个时候在1.0的基础上开发后续的功能,突然测试发现线上版本有BUG需要修复,我们需要怎么办?
svn:
上线的1.0版本已经归入到release分支下,我们的本地开发环境需要保存两套代码,一个trunk目录下的开发版本,一个release目录下的线上版本,假如你现在在做trunk的开
发,突然需要你切换到release代码,通常我们需要手动切换工作空间,人为的切换.
git:
使用git branch testing建立一个开发分支,然后开发,需要你切换到release分支的时候,使用git checkout release命令,切换完毕.
4.现在trunk分支已经开发完毕,测试也都通过了,我们怎么把trunk的代码合并到release分支呢?
svn:
通常有一种很原始的方法,就是trunk所有的修改文件都记录在一个列表里面,然后通过人工的复制粘贴来合并文件,
git:
首先使用git checkout release命令切换到release分支,再使用git merge trunk命令,合并完成.
就以我现在对git浅显的认识,我已经发现了如此之多的好处,那么我们为什么不做一些改变?
git给我印象最深的一个就是分支切换,另一个就是变基了
变基 : 你可以提取在 A分支 中引入的补丁和修改，然后在 B分支 的基础上再应用一次。 在 Git 中，这种操作就叫做 变基。 你可以使用 rebase 命令将提交到某一分支
上的所有修改都移至另一分支上，就好像“重新播放”一样。
觉得git能做的其他的工具也能做到
我们关注到一个新的工具,也意识到这个工具对我们来说是有帮助的,可是还有有很多人对此持怀疑态度,觉得没有作用,或者说git能做的svn也能做,其实这些说法本身没有错,我们用txt文本也能编码,那我们为什么要使用IDE呢,因为IDE能给我们带来方便,能代劳一些重复性的工作,提高我们工作的自动化程序.
觉得大家对这样的工具都不熟悉,学习使用起来麻烦
其实我们用到这样的工具,又不指望能成为git的专家,我们只是使用者,我们需要掌握的命令一共也就十个左右,有同事愿意做先行军,为大家总结使用手册,进行培训,你要做的只是一点点改变,为什么不呢?
觉得提升少,意义不大
有人认为你这样的工具对于我们整个软件开发的过程来说,提升不大,意义不大,我觉得从两方面,来说这个问题,一个是我们现在对工具不熟悉,工具还能带我们多少的惊喜,我们还不清楚,另一个方面,其实就是一句古话了
勿因善小而不为
只要我们承认这个工具能给我们带来好处,那么我们为什么不做呢?就因为觉得一点进步就不是进步吗?