SVN 和 Git 在日常使用中的明显差异

 合并对提交过程的保留

• git：合并操作保留原有的提交过程（即保留了合并来源的作者、提交次数、分离提交的内容）。
• svn：合并操作把来源多个提交合并成了一个合并提交，即在提交历史中Crash了自然的提交过程。

保留原有的提交过程，可以无需繁琐追踪历史就方便的

1. 跟踪修改过程。
2. 直接从提交中就可以看到原提交的作者信息，体现了对作者的尊重。
3. 自然的提交过程。这极大方便了代码细节演进过程的查看。
4. 极大方便查出那行提交是什么时间、谁做出的。
   svn因为合并Crash了自然的提交过程，要追踪很痛苦。

 修正提交

• git：可以修正提交。
  使用功能分支工作流，在自己的分支可以方便修正提交而不会影响大家。
• svn：一旦提交就到服务器上，实际使用中就是不能修改。
  （svn可以在服务器上修改，因为过程复杂需要权限实际上从不会这样做。）

实际使用中会有误提交的情况（如提交了一个不该提交的日志文件），对于svn来说，就是让大家一遍又一遍看到这个垃圾文件。

没有干净的提交，严重影响了Code Review，增加成本。

另外对于想了解演进过程的同学，垃圾提交影响了了解效果。

 廉价好用的本地分支

• git：有本地分支
• svn：无本地分支

git可以方便创建本地分支，且创建分支的时间是O(1)，即瞬间就创建好了。由于分支可以是本地的，也就不存在svn目录权限的问题。

可以从想要工作点闪电般创建本地分支，本地实验不确定的修改，创建分支如此之廉价，git推荐创建分支来隔离修改。

 更强大智能的合并能力

• git：重命名（无论文件还有目录）提交 可以合并上 文件重命名前的这些文件的提交。
• svn：重命名（无论文件还有目录）提交后，你本地/或是分支上 有文件重命名前的这些文件的修改或提交，在做合并操作时，恭喜，你会碰上传说中难搞的树冲突！

因为惧怕svn树冲突，在包名调整（重命名目录）或类名调整（重命名文件）前，我不得不先向一起开发的组员广播：

1. 提交你的修改
2. 暂停相关类的修改
3. 我开始做调整
4. 等我修改好后，你再开始修改

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）过程简直让我发狂。