关于git和svn的比较，求大家给点看法。

现在还是比较推荐git，分支，分布式，不依赖网络等。

svn比较适合团队集中式管理，统一一套代码
git比较适合开源分散式管理，每人一套代码

svn是上一代SCM的产物。

SVN基础结构脱胎于磁盘目录树，svn的一切分支/tag/合并均基于文件树结构操作，代码管理结构和源码目录结构混合在一起。中央管理，依赖网络。

git是重新设计的DSCM概念，基础结构基于commit树，一切操作都基于抽象的commit树，管理结构和源码结构彻底分离（但也因此不能像svn仅checkout出一个子目录）。分布式管理，网络是可选的。

我一直没用过SVN的分支，难用死了。

Git的分支，秒懂，秒用。

最明显的一点就是无网也能commit.

的确git的分支很好用，还有分布式管理就可以基于本地仓库进行修改，还有什么比较大的不同么？

svn工作时需要连上svn server
而git完全可以在离线的状态下进行版本更新，等在线时再将离线的版本push到共享库里

另外，git做分支很方便。可以做本地分支，在本地做试验性开发，开分支很方便。
svn要开分支就会同步到服务器上。

svn 需要你随时连接 server 才能工作， git 不需要 等有网络的时候 push 上去就好
另外 git 基于本地仓库的离线管理非常好用

git的暂存区 本地分支 真心赞.

公司用svn,自己一直都是用git-svn来做替代品.

@leopku
@verfino svn的仓库一样可以在本地文件目录里存放的,所以重点不是有网络无网络的时候是否可以提交,重点在svn是集中式的,仓库只有1个;而git这种分布式的,到处都是仓库

@BOYPT 怎么看都是Git比较容易理解，直接checkout新分支。虽然它的实现其实更复杂，但接口够简单。

补一句，能提交github

还能submodule

@tuoxie007 一旦接受了新式的良好设计理念就觉得svn那种方式很恶心了……

我的一些感受
1.本地提交，为完成的代码可以用版本控制，同事不影响线上代码
2.brach简单，方便
3.submodule可以维护一个核心，如果有多个项目，可以保持核心代码始终统一
4.只在根目录下有一个.git目录，不会每个目录下面都有一个.svn目录
5.web客户端的gitlab界面清新，便于审阅别人代码

Orz,抱歉,好多错别字
"1.本地提交，未完成的代码可以用版本控制，同时不影响线上代码"

All cool kids are using Git.

git 敲命令 记命令 没界面 适合无界面的工作者吧

不过好像已经有界面的了

@xdeng git也可以用小乌龟的

@welsonla 那有什么样的项目适合用svn么？git应该还不是所有各方面都比svn好吧？

个人用的话果断git更好; 多人开发没试过用git所以不知道

@xdeng sourcetree.app

git+repo 公司的android源码我都是这样管理的。

场景不一样， 优点可能是缺点。

你要说你在什么场景下用。

@angelface 恩，是的，主要是我svn不怎么用，所以不是很清楚，我就是想知道在哪种情况下用哪个比较好

@welsonla 用新版的svn就不会每个子目录都有.svn目录了

说一下我个人的感受。
svn本身偏向于c/s的开发，或者说是偏模块儿化或者松耦合的程序。svn可以单模块儿的上传。也可以单模块儿的更新。因为是单模块的更新，因此开发者完全不需要考虑其他开发者的变更，自己的开发也是完全在基础版本上更新来的。
对于svn来说，以前的瀑布开发很合适。一个开发组里面只要有一两个比较厉害的人，带着其他水平不怎么样的人做东西，其他的人都不提交代码，全部交给PL来合并代码，并维护svn。这样的话代码质量容易维护。在我看来，svn对于团队来说，update是所有的人事情，但是commit只是组长的事情。
git更适合b/s开发。现在的开发强调小步快跑。也就是说，要求不论什么时候，都要可以有一个快速的可以运行的版本。这样一来，就要时刻强调代码的完整性，最好每一版都是可以运行的。在svn上不是不可以做到，但是相比git比较麻烦。git是应该所有成员都update，都commit的。每次不管其他谁要commit代码，必须先保证本地的版本同服务器上的版本相同。这样一来，从逻辑上就保证了每一次commit代码后，都是服务器都是一个完整的版本。
git更要求整个team的组员都要有一定的水平，因为你每一次commite之前，都要去check一遍版本，如果有了别人的变更，你必须要先把变更合并了。这个时候，就需要考虑别人的变更是否会对你的变更有影响，这需要你对业务的熟悉，同时还要对其他人的编码熟悉。相当于原来组长的活，变相的分解成了组员的活。

个人试想了一下，在某种情况下svn还是占优势的。那就是有巨多的人在开发一个极其松耦合的程序。
假设你开发这个a模块儿，不管怎么折腾，都不会对其他模块有影响，其他人也一样。那么你就只需要up，commit自己的模块儿就好了。这样的话，如果所有的人开发完成，svn就是一个完整的版本。而不需要其他人来merge。
如果用git来做的，是，你可以自己创立一个分支自己玩，但是最后还是要有一个人来merge这巨多的人的代码。

git在分支管理与合并上有明显的优势。

影响我的是速度啊，速度，有的速度你就喜欢频繁提交了。
不过这个可能跟我用cygwin的git有关，tortoiseSVN实在是太慢了，遇到SVN的服务器在国外，有的你想喊FK。

我觉得从功能的强大上比较的话 git秒杀svn

svn在每个子目录下都要生成一套.svn目录，很麻烦

svn能做到的，工作流git都可以轻松搞定
git能做的，大部分svn只有呵呵的份

git能快速切换分支，svn的分支是一个新目录，下载也要很长时间。

用了 git 之后，再也不想回去用 svn 了。
上面99%的意见都是支持 git

@falconeye svn 有switch名片可以切分支。不需要下载全量的。

朱一公司用的svn 个人项目用的git

个人感觉基本没有什么区别。 都有对应的开发方式。唯一的区别是svn是中央管理。commit 都是直接 commit 到server的 git 是commit 到本地 再 push 到server。
分支合并都是一样一样的。没有git做得到svn做不到的事情。

还有是git不会有树冲突 svn再add 和 delete 操作之后合并分支再多人开发的时候会有树冲突的情况。

svn的优势是有些老人习惯了svn不愿意转到git, 他们会yy出各种svn的优点, 把那些人踢掉就好了

@zythum git的3种流行工作流除了集中式，剩下2种用svn怎么实现。参考：http://wangyan.org/blog/git-work.html
git的cherry-pick在svn中怎么实现
不装其它插件git的bisect在svn中怎么实现
等等等等

更不用说被人说最多的分支创建切换和合并。svn的merge不做特殊处理，仅当做是普通的一次提交，所有merge的信息和分支历史信息全部需要额外记录。svn的merge和git根本就不是一回事。参见下面3个链接：
http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn/2472251#2472251
http://stackoverflow.com/questions/2692950/whats-the-difference-between-svn-and-git-for-merging
http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2477089#2477089

觉得git不比svn有优势只能说是对git还不够了解。甚至对svn本身也没什么了解

cherry-pick 是合并一些commit 也不是全部。 svn可以用 版本差异merge来处理，提交分支某几个版本的差异合并。
bisect 只是工具么 用svn-bisect也可以的。插件实现就不算功能了啊。

svn和git内部版本树处理就不一样。当然不是一回事情了。
git 却是在易用上做的好一些。还能规避很多错误，但是功能大部分都是一样可以用的。

@luikore +1

@zythum 如果约定，配合，使用得当，版本管理工具也是可以省掉的

@sdpfoue 但是这个所谓的约定，配合，使用得当应该要相当理想化了吧，而且肯定会有很多额外的工作量

@jtn007 那是自然

如果是管理代码的话，如果你可以自由选择的话，没有什么理由不用 git。绝大部分 svn 能做到的 git 都能做到而且做的更好。而 git 能做到的，svn 做不到或者不好做。

但有一个功能是 git 做不到的，那就是 svn lock，这在有些情况下非常有用（例如管理doc，xls，psd，fla之类需要多人协作的二进制文件）

个人更喜欢 SVN
推荐你一个在线 SVN 仓库：svn.gzyunke.cn