讨论：Unity SVN vs Git，兼谈研究问题

米老鼠和蓝精鼠v · 发表于 2020-12-30 10:03

对于程序来说，项目，当然要使用版本管理，版本管理的发展，从最早期的cvs，到后来的svn，以及最流行的git，有了很多变化。从svn的中心化方式，到git的分布式方式，一路演进，当项目刚开始的时候，确定如果管理项目工程，美术策划，服务器，客户端如何合作的时候，选择一个合适的版本管理方式，是一个重要的决定。
我们在这里只讨论svn和git这两种最常见的，免费的方式，其他方式，不在比较讨论之列，这里，也只讨论游戏开发领域，不涉及其他研发领域。
在我看来，需要版本管理的项目，大概分两类：

然后，我们要看一个项目需要参与的人：

再说，不同部门，职能的人，对版本管理的理解程度，甚至英语的熟悉程度。

当我们在决定项目管理方式的时候，要综合考虑自己团队人员的能力，以及预估后续补充员工的素质程度。而不是基于程序自己的喜好来选择。客户端程序因为在整个游戏项目中，充当最后的整合者，通常也是整个工程的管理者（不是项目管理的意思），所以，应该从多角度来考虑技术方案。
我们通常要考虑几点：

大家看到，我列的几点，几乎都是针对策划和美术的方便的，并没有考虑程序是否方便，例如是否方便branch，merge等。
因为一个工具的使用，也是一个木桶原理，对于版本管理这个木桶，策划和美术是短板，美术是最短板（因为他们工作的资源，是非文本的）。
如果团队的美术，不是非常强大有经验，对版本管理非常熟悉，或者他们有能力和财力，安排一个专人管理。那么，我们就要从美术的工作方式去考虑，从策划的工作方式去考虑。
对于SVN和Git的工作方式，程序都很熟悉，我不必额外介绍，我只举几个例子，来模拟下工作流程的差别。
1，当策划修改了好几个配置文件a，b，c，d，这个时候，需要提交其中一个a。
在svn下，策划直接commit a文件，结束。
在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，也只是把git当svn用

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）就够了呢？或者很多时候，我们对模式的应用，并不应在其形式，而应是用其解决问题的思路。
很多时候，我们在没有以需求为前提，没有以问题为前提的情况下，空谈设计模式，框架，插件，工具的优劣和使用，都是没有太大意义的。

多研究些问题，少谈些主义

胡适在几十年前，就写下了&#34;多研究些问题，少谈些主义&#34;。我刚工作的几年，也喜欢各种设计，框架，模式。在经历过项目磨炼，成长后，逐渐认识到：一切东西，都应该返璞归真，从解决问题做起。
所以，今天想谈的，并不是svn和git之争，只是想由此说明：选择什么，都需要具体问题，具体分析。

		自动登录	找回密码
密码			立即注册

讨论：Unity SVN vs Git， 兼谈研究问题

讨论：Unity SVN vs Git，兼谈研究问题