GIT

这几天和团队的童鞋争论代码管理和代码发布流程

我入职以后，大家准备从 IBM RTC 上面迁移到 GIT。

争论点在于，如何用 GIT 来做集中制管理。

其实这是一个伪命题，先来说下什么广义的 集中制 管理吧。

我们平时所谓的团队管理，包括人员管理，任务分配，角色分配啊，其实都是集中制管理的一种。

集中制管理最大的特点就是，有人来做分配和验收。比如 DEV 有头头，QA 有头头。

事情都是头头来拍板，头头来分配，头头来承担对外责任。

所以，项目管理，来说，我们用的其实就是集中制的思路。

但是，GIT 是跟着集中制对着干的。

和他们讨论，听的最多的就是，我这个代码要上服务器，然后内谁谁去服务器上面拿就行了。

这种情况，难道不是你直接让对方来你机器上面 fetch 一下么？

答曰：这个太复杂了。

其实，这个并不是复杂，而是思维定势，说穿了就是笨和懒。

GIT 的精髓就在于 Branch 以及 fetch。并不是 pull 和 push。通过 local Branch 以及 fetch 别人的 Branch，来达到去中心化的目的。

把集中制的管理放到代码管理上是最顺的一种方式，所以 SVN 和 CC 这种代码管理比较合乎这些人的胃口。
但是一看 GIT 是潮流，于是就也要上 GIT，但是依旧沿袭着 集中制 管理的思路来做，各种尴尬不顺畅。

我们生活里和单位里习惯了被集中化的管理，文化中习惯了被中心化的管理。而去中心化的管理来自于开源社区的管理方式，我只需要一个人来接受 pull request 而这个 pull request 内容是一个人或者几个人自组织的。两者冲突与矛盾就立刻展现出来了。

结果呢，很多企业很多团队配合上各种流程文档约定，硬在 GIT 上搞了一套集中制的代码管理。还自鸣得意：这是适合我们的代码管理流程。

仔细想来，这其中不乏所谓的大公司，和大互联网企业。

如果你在的团队准备使用 GIT，但是团队中普遍有以下情况存在的，我建议使用 SVN。

• 以前就用 SVN 的
• 没有参与过开源社区的
• 又懒又笨的
• 不愿意建立 Local Branch 的
• 不能精确控制自己 Commit ，喜欢一股脑儿提交代码的
• 喜欢用 Eclipse GIT 插件的
• 觉得 Branch 这事情应该是 Integrator 管的
• 不懂还瞎说的
• 不懂瞎说还不愿意学习的
• 不懂瞎说不愿意学习并且还喜欢和你争论的