讨论：Unity SVN vs Git， 兼谈研究问题
对于程序来说，项目，当然要使用版本管理，版本管理的发展，从最早期的cvs，到后来的svn，以及最流行的git，有了很多变化。从svn的中心化方式，到git的分布式方式，一路演进，当项目刚开始的时候，确定如果管理项目工程，美术策划，服务器，客户端如何合作的时候，选择一个合适的版本管理方式，是一个重要的决定。我们在这里只讨论svn和git这两种最常见的，免费的方式，其他方式，不在比较讨论之列，这里，也只讨论游戏开发领域，不涉及其他研发领域。
在我看来，需要版本管理的项目，大概分两类：
服务器：纯代码加上文本类配置，所有的东西，都是文本。客户端：包含代码，配置（文本，非文本），以及美术资源的综合。
然后，我们要看一个项目需要参与的人：
服务器：服务器程序和策划。客户端：客户端程序，策划，美术。
再说，不同部门，职能的人，对版本管理的理解程度，甚至英语的熟悉程度。
服务器，客户端程序：理解度高，通常能阅读理解英文技术文档，英文相对可以。策划：理解度一般，但因为和程序更需要密切合作，学习能力相对不错。英语能力通常不好。美术：理解度低，美术因为工作性质相对独立，他们对于版本管理的概念和需求都没有那么强烈，并且通常对技术类知识的学习能力较差。通常英语能力也比较差。
当我们在决定项目管理方式的时候，要综合考虑自己团队人员的能力，以及预估后续补充员工的素质程度。而不是基于程序自己的喜好来选择。客户端程序因为在整个游戏项目中，充当最后的整合者，通常也是整个工程的管理者（不是项目管理的意思），所以，应该从多角度来考虑技术方案。
我们通常要考虑几点：
策划，美术使用是否方便，会否增大他们的无谓工作量策划，美术的学习成本有多高策划，美术团队的能力，能否跟上对应的解决方案工作方式沟通和解决问题是否方便
大家看到，我列的几点，几乎都是针对策划和美术的方便的，并没有考虑程序是否方便，例如是否方便branch，merge等。
因为一个工具的使用，也是一个木桶原理，对于版本管理这个木桶，策划和美术是短板，美术是最短板（因为他们工作的资源，是非文本的）。
如果团队的美术，不是非常强大有经验，对版本管理非常熟悉，或者他们有能力和财力，安排一个专人管理。那么，我们就要从美术的工作方式去考虑，从策划的工作方式去考虑。
对于SVN和Git的工作方式，程序都很熟悉，我不必额外介绍，我只举几个例子，来模拟下工作流程的差别。
1，当策划修改了好几个配置文件a，b，c，d，这个时候，需要提交其中一个a。
在svn下，策划直接commita文件，结束。
在git下，策划可能预先需要开一个branch，改了a，b，c，d，分别commit，然后切回develop branch，merge a的commit，然后push。甚至，在push之前，不得不做一次pull。这块可以参看git对已有项目上传单个文件 - CSDN博客
2，当策划A只想更新策划B改的skill_cfg这个配置
在svn下，只需要对单个文件，执行update即可
在git下，参看git更新单个文件方法 - CSDN博客
从这两个简单的方式看
svn的操作是简单直观的，不需要额外的理解成本。而git，需要策划美术理解分布式的概念，理解光commit，其他人其实更新不到，理解pull和push，甚至需要理解branch。有些项目，即使用了git，也只是把git当svn用。对于很多懒的程序，他们都没有仔细学习研究过git，把git用对。我见过有项目，用了git，但是实际上只有一个master分支，并没有做到每个功能划分一个branch的工作方式，那么，用git干啥啊。git对美术策划，额外的工作成本太高。对于美术来说，svn已经让他们难以理解了，他们甚至不会注意处理冲突，不记得提交unity的meta，不会使用lock。那么，我们能奢望他们去使用git吗？git不符合策划，美术的工作思路。对于策划来说，单个文件，单个目录的提交，更新，是他们的日常操作。让他们额外去理解一层git的工作思路，对他们不是一个额外的伤害吗？git的沟通成本，学习成本更高。当然，程序可以抱怨团队素质不高，抱怨他们怎么啥都不会，啥都不学，但是，我们也要从实际来出发。
有些很强的团队，或者人员够多，其他美术只是汇总资源到专门的提交者这里，由专人提交资源。或者团队成员都有多年工作经验，愿意学习新东西，并且我们程序能做到很好地培训他们对版本管理，研发方式的认知。这类情况，尚可以尝试用用git，否则，给美术策划带来的麻烦，就太多了。
总的来说，git的思考方式，不够直白简单，不太适合非技术人员使用。并且，git更适用于文本类项目，例如服务器开发，但是，并不太使用以二进制为主的项目，例如以美术资源为主的客户端。
当然，有些项目会将客户端的代码和资源分成两部分来管理，资源用svn，代码用git，这也是一种方式，但是要处理要两者衔接的中间部分，处理不好，也是一个麻烦。
早年我也在项目中推行使用git，但是看到策划和美术的不适应，加上站在项目合作的角度去考虑问题，就还是用了svn。svn在新版本，处理好零散的.svn文件夹的问题后，已经非常好用了。唯一的问题，主要就是在需要分支的时候，处理起来没有git方便，但是宁愿程序偶尔麻烦一下，不要让美术策划一直麻烦。
实践是检验真理的唯一标准
这里写一句大话，主要是看不惯程序领域内的一些现象，动辄说SVN是过时的了，git才是先进的，根本不考虑适用场景和团队合作的问题。而且还形成了鄙视链，很奇怪的是，一些蹩脚的用着git的人，看到别人用svn，不问缘由，就开始鄙视。还看到知乎有回答说腾讯用svn为主，不用git，就说明腾讯技术能力低一截，这个思维模式，还真是不敢苟同。还有用各种lua（slua，ulua，xlua）的互相还看不上一样。
追快求新的装B心态，导致了很多程序，工作多年没有成长，没有积淀。一味追求一些高大上的技术名词，却没有静下心来，分析需求，分析问题，解决问题的能力。（面试见过很多工作多年，一塌糊涂的人）
就像我之前讨论的，为什么我不想在游戏开发中使用MVC，任何一个技术，一个设计模式，都是遇到了问题，才设计一个解决办法。不应该觉得那个模式好，就生搬硬套。即使在开发游戏UI的时候，真的确定需要MVC吗？有些情况，是不是用观察者模式（Observer pattern）就够了呢？或者很多时候，我们对模式的应用，并不应在其形式，而应是用其解决问题的思路。
很多时候，我们在没有以需求为前提，没有以问题为前提的情况下，空谈设计模式，框架，插件，工具的优劣和使用，都是没有太大意义的。
多研究些问题，少谈些主义
胡适在几十年前，就写下了"多研究些问题，少谈些主义"。我刚工作的几年，也喜欢各种设计，框架，模式。在经历过项目磨炼，成长后，逐渐认识到：一切东西，都应该返璞归真，从解决问题做起。
所以，今天想谈的，并不是svn和git之争，只是想由此说明：选择什么，都需要具体问题，具体分析。
页:
[1]