👉 Why I love to use git rather than svn!
自己在使用git过程中相对svn的感受强烈的变化。
git：合并操作保留原有的提交过程（即保留了合并来源的作者、提交次数、分离提交的内容）。svn：合并操作把来源多个提交合并成了一个合并提交，即在提交历史中Crash了自然的提交过程。
保留原有的提交过程，可以无需繁琐追踪历史就方便的
- 跟踪修改过程。
- 直接从提交中就可以看到原提交的作者信息，体现了对作者的尊重。
- 自然的提交过程。这极大方便了代码细节演进过程的查看。
- 极大方便查出那行提交是什么时间、谁做出的。
svn因为合并Crash了自然的提交过程，要追踪很痛苦。
git：可以修正提交。
使用功能分支工作流，在自己的分支可以方便修正提交而不会影响大家。svn：一旦提交就到服务器上，实际使用中就是不能修改。
（svn可以在服务器上修改，因为过程复杂需要权限实际上从不会这样做。）
实际使用中会有误提交的情况（如提交了一个不该提交的日志文件），对于svn来说，就是让大家一遍又一遍看到这个垃圾文件。
没有干净的提交，严重影响了Code Review，增加成本。
另外对于想了解演进过程的同学，垃圾提交影响了了解效果。
git：有本地分支svn：无本地分支
git可以方便创建本地分支，且创建分支的时间是O(1)，即瞬间就创建好了。由于分支可以是本地的，也就不存在svn目录权限的问题。
可以从想要工作点闪电般创建本地分支，本地实验不确定的修改，创建分支如此之廉价，git推荐创建分支来隔离修改。
git：重命名（无论文件还有目录）提交 可以合并上 文件重命名前的这些文件的提交。svn：重命名（无论文件还有目录）提交后，你本地/或是分支上 有文件重命名前的这些文件的修改或提交，在做合并操作时，恭喜:see_no_evil:，你会碰上传说中难搞的 树冲突！
因为惧怕svn树冲突，在包名调整（重命名目录）或类名调整（重命名文件）前，我不得不先向一起开发的组员广播：
- 提交你的修改
- 暂停相关类的修改
- 我开始做调整
- 等我修改好后:scream:，你再开始修改
OMG～ 😖～～
因为这个过程烦琐，结果就是影响了大家去做这样重构操作的积极性，进而影响项目的代码质量改进！
别忘了，如果你的项目是开源的，全球的人可以给你提交，可没有办法向全球的同学广播 😗
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）过程简直让我发狂。