从企业开发流程到使用场景解析 git vs svn

一、svn和git简介

git和svn都是一种代码托管方式：通过将本地代码提交至远程仓库，来实现企业级程序开发。

虽然git和svn都能实现代码的版本控制，但是二者的工作方式以及对应的开发流程是截然不同的，根本原因在于**git是分布式版本控制，而svn是集中式版本控制**

二、从企业开发流程上看git VS svn

举个例子，当我们加入一个使用git托管代码的团队时，开发流程如下：

1. 刚进入团队后，必须先拉取团队代码，此时一般使用git clone命令将master分支克隆到本地。master分支一般是线上服务正在运行的代码。
2. 后续接需求后，一般是从最新的master分支上拉一个最新的需求分支（通常以需求命名）。本需求涉及到的全部功能，均在需求分支上实现。个人以为，这也是git最强大的功能之一——本需求开发期间能够避免受到其他并行需求的影响。比如，我在我的需求中修改了方法a，其他人在别的需求中也要修改方法a，但是我只是修改了我的git分支，别人不会过来修改我的分支，只要我和别人不是同一天上线，那么在后上线的就一定会感知到先上线的人对方法a的改动。这样就能避免一些隐形的代码冲突。
3. 等需求开发结束，进入联调阶段前，需要将master分支代码 -> 需求分支。因为在该需求开发期间，可能会存在一些并行需求的上线将其他需求分支代码合入了master。也就是说，进入联调前，要确保本需求分支能够包含最新的master分支代码
4. 等到需求上线的当天，我将我的分支 -> master分支，并且通告其他同事：master分支有更新，辛苦各位在各自分支拉取最新的master代码。
5. 上线后，如果要修线上bug，可以再从master上拉一个新分支，然后按照上述流程 -> master分支

这样看来，git的优缺点也很明显了。优点在于git分布式开发能够天然支持并行需求的代码实现相互隔离（也就是每个人在自己分支上只能看到同分支的代码，看不到并行需求的未上线代码的，因为不同需求都有各自的分支），缺点是每一次master分支有重大代码变更都需要拉取到自己的需求分支并及时处理冲突。

如果我们加入一个使用svn托管代码的团队呢？开发流程如下：

1. 进入团队也是需要拉取团队代码，这主要使用svn的检出命令，将托管服务器上的代码copy到本地
2. 接了需求以后，不需要提前拉分支，直接在trunk（主干）上开发。很多人将trunk类比git中的master分支，这就错了。因为没有提前拉分支，所有人都在trunk上开发，所以**trunk上是能够看见并行需求的未上线的代码的**。这一点是熟悉了git开发的同学比较迷惑的，为什么不能像git一样提前拉好分支，大家各自在自己分支上开发，而是要在trunk上一起开发呢，这样很容易出现我要上线了，别人还没开发完，但是我们修改了同一个文件，我要上线岂不是要把他没写完的代码带到线上去么？从理论上说，确实存在这种很可能，但这是svn不能避免的一种风险。怎样规避这种风险，一个简单的办法是给每个人的功能都加上开关，开关是否打开要以配置的方式实现。
3. 我的需求开发结束了，进入联调前也不用拉取最新的trunk代码，因为trunk分支上一直是最新的代码。将trunk分支部署到服务器上开始联调就行了
4. 上线前，需要从trunk上拉一个新的上线分支，这个分支就包含了我需求的全部内容，同时也会包含并行需求的已提交内容。上线时使用该上线分支。
5. 如果上线后出现了bug，优先在上线分支修复bug，然后还要同步到trunk分支

这样看来，svn相比于git好像没有什么优点，不能实现并行需求的隔离是硬伤，修bug还要在两个分支上修。但svn存在就有存在的道理，从开发流程上看svn并不占优势，那我们接下来再进行一下详细的对比，你就知道为什么还有这么人/企业在使用svn了

三、从使用场景上看git VS svn

一个远程仓库，可以托管代码，也可以托管一些静态文件（比如图片、视频demo、美术资源等等）。

• 如果项目只需要使用远程托管代码，代码再多逻辑再复杂，存到仓库中就是一个个的文本，占不了很大的存储空间。此时，使用git完全可以胜任代码提交（包含提交比对）、代码推送、代码拉取等功能。注意，git提交是不用和远程仓库交互的，仅在本地就可以提交。因此，大部分互联网的web后端大多采用git托管代码
• 如果项目中含有较多的美术资源文件，代码仅占据一小部分，此时再使用git作为托管方式就不太适用了。因为美术资源并不能像代码一样方便的切分支、合并文件、对比文件。因此，一些游戏公司还继续使用svn来托管代码。并且，svn上手难度低，项目中除了程序员之外的其他职能人员也能低成本入门。