合并对提交过程的保留
git
:合并操作保留原有的提交过程(即保留了合并来源的作者、提交次数、分离提交的内容)。svn
:合并操作把来源多个提交合并成了一个合并提交,即在提交历史中Crash了自然的提交过程。
保留原有的提交过程,可以无需繁琐追踪历史就方便的
- 跟踪修改过程。
- 直接从提交中就可以看到原提交的作者信息,体现了对作者的尊重。
- 自然的提交过程。这极大方便了代码细节演进过程的查看。
- 极大方便查出那行提交是什么时间、谁做出的。
svn
因为合并Crash了自然的提交过程,要追踪很痛苦。
修正提交
git
:可以修正提交。
使用功能分支工作流,在自己的分支可以方便修正提交而不会影响大家。svn
:一旦提交就到服务器上,实际使用中就是不能修改。
(svn
可以在服务器上修改,因为过程复杂需要权限实际上从不会这样做。)
实际使用中会有误提交的情况(如提交了一个不该提交的日志文件),对于svn
来说,就是让大家一遍又一遍看到这个垃圾文件。
没有干净的提交,严重影响了Code Review
,增加成本。
另外对于想了解演进过程的同学,垃圾提交影响了了解效果。
廉价好用的本地分支
git
:有本地分支svn
:无本地分支
git
可以方便创建本地分支,且创建分支的时间是O(1)
,即瞬间就创建好了。由于分支可以是本地的,也就不存在svn
目录权限的问题。
可以从想要工作点闪电般创建本地分支,本地实验不确定的修改,创建分支如此之廉价,git
推荐创建分支来隔离修改。
更强大智能的合并能力
git
:重命名(无论文件还有目录)提交 可以合并上 文件重命名前的这些文件的提交。svn
:重命名(无论文件还有目录)提交后,你本地/或是分支上 有文件重命名前的这些文件的修改或提交,在做合并操作时,恭喜,你会碰上传说中难搞的树冲突!
因为惧怕svn
树冲突,在包名调整(重命名目录)或类名调整(重命名文件)前,我不得不先向一起开发的组员广播:
- 提交你的修改
- 暂停相关类的修改
- 我开始做调整
- 等我修改好后
,你再开始修改
OMG~ ~~
因为这个过程烦琐,结果就是影响了大家去做这样重构操作的积极性,进而影响项目的代码质量改进!
别忘了,如果你的项目是开源的,全球的人可以给你提交,可没有办法向全球的同学广播
一等公民支持tag
svn
在模型上是没有分支和tag
的。tag
是通过目录权限限制(对开发只读)来保证不变。git
模型上一等公民支持tag
,保证只读。
内心是不是有强烈的安全感?
完整配套的开发过程设施
与git
配套的github
、gitlab
(我们公司搭建了)提供了:
Markdown
:高效的文档编写和查看。Issue
&Milestone
:问题记录&跟踪,任务分配,版本规划&管理Wiki
系统:体系的文档- 评论:可以对代码提交(即是Code Review)& Issue做评论。
这个有记录交流的过程。
记住,上面的一切和代码一起集中管理,是以代码为中心的,可以方便的工程中的代码。
可运行并完成功能的代码(且叫目标代码) 才是整体项目真正生效的产出。
一切不为 目标代码 服务 的东东都是 流氓!
# 是不是想到很多东西(比如下压式的排期计划)会觉得自己是生效的产出,好像剩下的事就是 码农搬砖一样把代码码好。
热操作有闪电般的速度
提交
git
提交是个本地操作,相对svn
闪电一般。git
提供了暂存区,可以方便指定提交内容,而不是全部。
PS:git
可以只提交一个文件修改的一部分而非全部(git add –p
),使用相对繁琐些。(实际上开发中我很少这么做)
这让开发者更愿意整理提交,让每个提交更内聚自包含。进而有利于
Code Review
- 线上
Bug
的快速准确的回滚式修复
查看日志
查看日志是个频繁的操作。
git
:本地包含了完整的日志,闪电的速度(并且无需网络)。svn
:需要从服务拉取。
一旦用了git
后,等待svn
日志(包括查看2个版本间的diff
)过程简直让我发狂。