svn服务器搭建（svn本地服务器搭建）

转手翻开《精通git》，看看这400页都讲了些啥。只能说刚学git的时候每一次提交都要问问前辈，就怕把仓库弄出问题。

我们的git基本相当于svn，如果是分工明确，公司内部，那git基本上=svn，如果涉及外部协作，多人互撕，那git就是git。

git一点也不简单，我已经遇到了无数个认为revert就是把本地代码更新为服务器代码的同事。用惯了svn的人表示这么多分支，自己用好爽，跟人对齐真是工程量浩大。

老码农项目上第一次接触git，发现这玩意用不好是真不如svn啊。我们项目上现在用的就非常不好，经常出问题，经常出现代码不同步导致打的补丁不是最新版的问题。

我们是这么用的，一个人一个分支，如果出补丁，就新开一个分支里面只放你出补丁的这几个类，然后专人拿这个分支的类去出补丁打到测试或者生产环境上。

看起来没啥问题，就是经常出现打补丁少类或者代码不同步的问题，经常出现打的补丁不是最新版代码的问题。

如果是svn，版本库里始终是最新版，出补丁打到服务器上肯定是最新版，就没毛病了。

git用好了挺好，用不好出问题更多啊。

公司项目、源码管理混乱是什么样的体验？说说我经历过的几家公司项目和源代码管理的问题。

先说一个好的，我第一家公司是个游戏公司，源代码管理应该是最优秀的一家公司了。首先说注释，几乎每个复杂的接口都会把注释写的清清楚楚，普通接口还要写上接口是干嘛的等等。公司只用SVN保存源代码，每次上传一部分代码，都要在SVN的日志里写上本次上传目的、改了啥、谁让改的等等，源代码无论哪个人拷过去都能运行。

我一直以为这是常规操作，直到到了我上家公司。上家公司几乎所有接口都没写注释，业务逻辑还复杂，旧项目甚至连个项目文档都找不到。所以每次要修改代码时，都要从头把业务逻辑理一遍，但是乱就在于，上家公司每个业务逻辑都是以插件形式编写的，插件和插件之间还存在耦合的关系，这就导致了光看那一部分代码还不行，需要把所有相关插件的逻辑全部凑到一块去，才能理清他们之间的业务关系。有时候你会发现，耦合的插件还跟另外一个插件耦合，然后看到最后感觉自己碰到了圆周率，无穷无尽的翻代码。

然后就是数据库不写注释，上家公司数据库有上千个表，每个表的所有字段均没有写注释，不光这样，几乎所有数据库字段用的都还是简写，所以，当遇到涉及到字段的问题时，经常要问那些老员工。老员工记性好点的能给你想起来是啥意思，但是很多字段到后来大家都不知道是啥意思。

上家公司自从我入职以后，只要SVNShowLog里有写日志的，那保准是我写的，数据库字段有注释的，保准是我后面添加的字段。

我原本以为我上家公司已经够离谱了，但是离谱的是我现在这家公司，把混乱发挥的淋漓尽致。上家公司有的问题他都有，而且代码还不喜欢复用，经常是同一个逻辑，能在每个项目里重新再复制一遍，结果后果可想而知，一个项目里发现问题，得把所有项目都拿出来改一遍。

还有就是源码存储方式，有存在SVN的，有存Git的，这对我来说，感觉都还是正常得了。

我经常打开以前的旧项目，一些相关的依赖项都在源码里找不到，我还得到处去找这些依赖项，有些客户的服务器我们是能登的，只能直接去客户服务器里找。但是我们公司大多数客户对安全要求较高，项目只在内网里跑，有些依赖项实在找不到，那是真急。只能打电话给以前编写这个项目的人去要。

最让人头疼的在于，我们这边写架构的，经常喜欢以打补丁的方式凑逻辑。一般来讲，项目后期，为了保证项目的稳定性，写个服务，或者附加程序也很正常，但是我们现在偏偏是在立项的时候，架构这边就已经决定把某些东西分开写了。

就拿我们上一个项目来说，是个BS项目，这个项目依赖四个服务，以及一个应用程序，这五个依赖项有一个没开系统都运行不了或者运行没数据，每个依赖项的配置文件还要单独配置。

一个好的项目管理以及源码的管理方式，直接决定在维护这些项目时，维护者的心情。如果项目和源码非常混乱，我宁愿再写一套，否则拿我去祭天我也愿意！