65
回答
Git 不适合公司内部组织使用,正式放弃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还是可以使用的。

Git
举报
中山野鬼
发帖于6年前 65回/22K+阅

以下是话题补充:

  • @中山野鬼 :我要额外重复三个观点: 1、没有什么万能的工具。GIT有价值,但有些情况下GIT不适合。 2、什么工具都能用,主要在人是否灵活掌握工具。这个观点我是反对的。例如用C语言开发桌面APP,不是不能开发,而是是否值得去做。 3、GIT并不适用公司组织化开发,准确说对一个版本或一个分支内部,多人的协同开发。这个和开源开发的形式差异非常巨大。 如果认为GIT在开源里成功,而认为上述第3点的组织化下开发GIT也很适用的话,最后吃苦的还是整个团队。 (6年前)
  • @中山野鬼 :另外,如果你是个程序员,反对我的观点。我觉得很正常。但如果你是个公司项目管理者,我建议你看清楚我的文章再讨论,你的决策失误会影响整个团队。除非你手下的人大多可以独自揽一摊子工作,否则公司内慎用GIT。 (6年前)
  • @中山野鬼 :最后说一下,貌似GIT的问题很吸引人讨论。我就此封贴(我个人不再参与讨论),只想建议大家,多从管理项目的角度,管理人力资源行为规范的角度,管理项目进度的角度,想问题。当然GIT的价值很明显,在很多开发场合很适合。是否适合你带的团队,还是得你自己判断。 (6年前)
共有65个评论 最后回答: 3年前

git 在win下没有好的配合vs的插件,暂时还没有用过,目前用的还是svn

(本地开个svn,写个命令每天晚上同步到服务器也很方便)

对于你所指的版本对齐,按照你的意思,任何版本工具都会有,但是git能有自己的本地版本。

对于你所指的版本控制,git更好,因为它能方便的创建分支以及本地版本,不会造成丢失,集中式只能多选一,万一哪天发现a版本不行,需要b版本呢?

引用来自“竹竿”的答案

你所指的对齐和冲突 其他版本管理就没有了么??

其他版本也有特别是集中式的版本管理。通常更强制要求每次上传都要合并,目的是去冲突和对齐。

GIT弱化这块,我觉得是对的,因为开源开发的时候,你甚至不知道谁参与的。因此很难对开源开发的参与人员进行组织。这对参与人员自身的要求很高。要求其能完整解决或者实现某个模块,此时该模块和主线之间的耦合度很低,GIT弱化这块,即可以提高开源参与者开发过程中的协同性约束,同时也可以通过开发者独立可处理完整模块,来尽可能降低冲突和对齐问题的影响范围。

--- 共有 1 条评论 ---
野薯每次push时,都应该rebase一下 6年前 回复

引用来自“竹竿”的答案

对于你所指的版本对齐,按照你的意思,任何版本工具都会有,但是git能有自己的本地版本。

对于你所指的版本控制,git更好,因为它能方便的创建分支以及本地版本,不会造成丢失,集中式只能多选一,万一哪天发现a版本不行,需要b版本呢?

你看到的是GIT所适用的,但有个前提是,使用GIT的人,可以独立对模块进行完整处理。如果模块的开发过程中,需要多阶段的和别人协同同步,此时用GIT就会很麻烦。而公司内部的开发,特别是组织化的,协同是非常重要的一个内容。
--- 共有 4 条评论 ---
中山野鬼回复 @地皮鼠 : 哈,,,分工好不好看开发效率和开发质量。而不是看用什么工具。 6年前 回复
野薯回复 @中山野鬼 : 也许git确实不适合你们,也许你们分工不太对 6年前 回复
中山野鬼回复 @地皮鼠 : 可能你们rebase的工作,代码分离很大。如果代码之间相互嵌套的很多时,rebase是个非常折磨人的事情。同时会有一些错误被忽视。 6年前 回复
野薯没觉得麻烦。经常rebase. 6年前 回复

策略-方法过程-工具,工具可以定制适应任何process,两个不同层面不宜直接compare;

git缺省的过程对组织过程改进有一定引导作用,可以采其积极一面;

对齐的习惯说法为merge,有正向,逆向,复合之分;

其中三方归并技术为araxis merge最早商业化,git随之;

楼主想说又说不清,帮一帮,无他。

--- 共有 2 条评论 ---
野薯回复 @中山野鬼 : 我们现在就用git: git+gerrit+hudson 6年前 回复
中山野鬼哈。我该说的已经说清楚了。组织化开发,和GIT的开发,是两个完全相反的方式。 6年前 回复
同感,一个web工程,无法针对目录分配权限,也就无法两个部门(技术部产品部)协同工作,只能继续沿用爆慢的svn。
顶部