git不适合

前段时间忙数学证明，回头要开始写代码了。又重新读了一下GIT方式，或者GIT管理代码开发的精神。发现至少不适合我的组织化开发的行为模式。因此打算放弃。

当然GIT作为一个linux下的工具，还是会用的。只是开发的组织行为不会和GIT的方式统一。

现在最矛盾的是merge。诸位谁有好的linux下的merge软件，也望推荐一二。当然至少要不比win 下的 araxis merge差。

同时，要抽象说明一下，GIT的方式，不适合公司内部作为项目组织管理。任何项目组织的版本管理软件，核心要解决的问题，如这个名词段的内容：

1、版本对齐

2、版本冲突

对齐，就是组织化分工后，不同单位之间的协同，无论是小到个人，还是大到开发组。

冲突，是同样的设计空间（目标，代码），不同组，不同人之间差异性描述的抉择。

简单举例：A，B两个人，相互之间的代码，要存在同步对齐。否则A，B的代码会差异越来越大，甚至有死锁。A写的函数必须等待B的函数实现才能测试，但B的函数需要等待A的函数实现正确才能验证。这是对齐问题。

而A，B两人同时对一个功能区域进行修改时，就存在二择一的工作。这是冲突问题。

GIT确实解决了很多问题，但是核心的两个问题，有回避和偷换概念的嫌疑。无论是提交者冲突问题，还是不同子服务器的版本对齐问题。

为什么放弃GIT方式开发，也就是由此导致的。公司内部组织化开发行为，存在明确角色定位。否则就不是组织化开发。而GIT的方式回避或者弱化了冲突问题的决策者，和对齐问题的决策者，至少在这方面的管理上，没有对应功能强化，由此，公司内部开发，会形成组织结构和使用工具的混乱局面。

当然并不是说GIT没有存在的意义。对于非公司内部的组织化开发，特别是对于开源方式的开发，（不是开发后的软件开源，这是两个概念，前者着重强调的是在项目开启和任意时间节点中，不确定后续开发者的明确角色，任务，后者只是强调代码是否公开），GIT对上述角色回避是有存在价值的，因为开源方式的开发，除了主维护者以外，其他角色都是动态和未知的。

但对于公司，组织化行为而言，你可以软件项目经理这个自然人未知，但主管某个模块的职务必须要明确。否则，项目无法组织化切割。

没有组织化切割，则公司就失去了通过专业人员聚焦的方式，获取低成本产出的可能。也即这个模块是人都可以做，没有谁一定只适合做，或一定不适合做他这么一说，如果公司内部开发是这么管理，成本和产品质量可想而知。

由此，GIT方式，并不适合公司内部组织化使用。重复观点，GIT方式在刻意回避角色问题。

补充，不过作为公司开发内部，最小单元，小组，小组内无角色差异性时，他们之间的版本工具，GIT还是可以使用的。