作者sunsamy ()
看板Soft_Job
标题Re: [请益] git上团队开发观念
时间Tue Jun 20 21:34:44 2017
回答得很好,可惜不实事求是
不过这也是乡民的风格
可能乡民不擅常独立思考
自已也没写过版本控制软体
1. 先回答git flow错在那:
{
首先连git flow自已网站都说自已无法保证正确无误
http://bit.ly/2t08DOT
--> 越是多的人参与进来,就越难保证每次合并正确无误。
这会造成"合并会错,是你修行不够,你的问题"的错觉
事实上这样设计版本控制软体"永远不可能保证协作百分之百正确"
因此你後续要花很多时间在收拾残局
当然git flow後续在软工与验证的观念错误更多
待你慢慢去发掘
程度不够的可能一个都找不出来
}
2. 再来是原作者使用git flow会错在那:
{
6. 小A,小B,小C开始进行开发时,本身对自己的localRepo上对dev开发。
--> 从这个时间点起,A、B、C的开发都是错的
因为A、B、C正在开发的都是彼此假设其它两方"正在开发的东西不存在"
所以後续会有一堆事情要收拾
一个简单的协作也能搞成这样
简值是垃圾软体
}
谎言有多种方式,一种是说纯粹的假话,另一种是说半真半假的话。
如果只看那一半真话,确实是对的,但看全部的话,仍然是谎言。
所以说,半真半假的谎言更危险。
在分析这种谎言的危害时,如果把真假两部分独立分开分析,是危险的。
只有整体分析,才能深刻地看清这类谎言的本质目的,从而避免坏 的结果发生。
<以上这些话取自小光>
以上已经探讨了谎言的几种方式。
其中,「半真半假」的谎言是最难识别的
另一个识别是否是正确协作的方式就是:
用起来会不会越用越复杂?会的话那就是错的,因为effort在发散
git flow跟敏捷文化发就是这种「半真半假」的谎言
一堆似是而非的观念充斥其中
当然有正确的协作方式,有机会再分享
※ 引述《tomtang0406 (自砍D文之王)》之铭言:
: ※ 引述《sunsamy ()》之铭言:
: : 身为一个程式设计员,竟然会相信git flow?
: 身为一个程式设计员,竟然会相信程式语言?
: : 跟相信敏捷文化的义和团有什麽不同?
: : 难道都没发现git只会产生麻烦,不保证正确且越弄越复杂而已?
: 难道都没有发现使用程式语言只会产生麻烦,不保证正确还要 debug,越弄越复杂而已?
: : 不信相的话查看看软体版有多少人在问git的事
: 不相信的话查看看软体版和 StackOverflow 有多少人在问程式语言的问题
: : 一个简单的协作,因为一个git tool的出现弄得鸡飞狗跳
: 客户一个简单的需求,就因为要写程式就弄得鸡飞狗跳
: : 还要出一本书才能掩盖这个tool的无能,结果还是不能保证协作百分之百对且越弄越复杂
: 每个程式语言都还要各自出版 N 本书才能掩盖这个程式语言的无能,结果还不能保证
: 工程师可以百分百正确做出客户的需求
: : 好了,在ptt不能讲太多事实!!!
: 真的!完全认同 ptt 不能讲事实!!!
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.126.250.214
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1497965686.A.8BD.html
1F:推 crossdunk: 战起来站起来 06/20 21:50
2F:→ reichs: 任何一套版控软体都无法做到正确无误的合并. 06/20 21:54
3F:推 gitignore: 为什麽我在国外待过的大公司都在用gitflow或类似的? 06/20 21:54
4F:→ reichs: 小A,小B,小C都不知道对方在开发啥,软体又怎麽可能知道 06/20 21:56
5F:→ gitignore: abc都不知道对方在干吗 这完全不敏捷阿... 06/20 21:56
6F:→ dreamnook: 他都脑内版控跟嘴炮程式码 当然不需要(¿ 06/20 22:01
7F:推 abc0922001: 战起来~~ 06/20 22:41
8F:推 abc0922001: 多人协作会冲突很正常,所以git merge有冲突会标示 06/20 22:47
9F:→ abc0922001: 冲突的地方。集中式版控就是保证你修改的时候别人 06/20 22:47
10F:→ abc0922001: 不会修改同一个档案 06/20 22:48
11F:→ Argos: 正确的协作方式就是要管制阿 不然再好的制度 使用者脑包一 06/20 23:10
12F:→ Argos: 样大家整天干干叫齁 说到底就还是人的问题 06/20 23:10
13F:→ ssccg: 协作不协作不是重点吧,一人改开多个branch最终也是要merge 06/20 23:11
14F:→ fjm31714: 请问大大终极解法是什麽呢? 06/20 23:13
15F:→ ssccg: 知道别的地方在改什麽对避免冲突感觉也没什麽帮助,真要完 06/20 23:15
16F:→ ssccg: 全避免就是完全不平行开发,changeset有重叠到就等等等吧 06/20 23:17
17F:推 SuperCry: 小光是谁 进藤光? 06/20 23:22
18F:嘘 Raymond0710: 重点还是在人身上 战工具?呵呵 06/20 23:30
19F:推 lovdkkkk: 就算能正确合并 合并出来的东西也可能有逻辑错误 06/20 23:56
20F:→ lovdkkkk: 所以不管怎样都要 review 比较好 06/20 23:57
21F:→ sorryla: 楼上,所以这跟工具根本无关,跟人怎麽用有关 06/21 00:01
22F:→ pythonista: 人都会犯错,软体应该要做到的是怎样可以方便处理这些 06/21 00:10
23F:→ pythonista: 错误吧 06/21 00:10
24F:→ netburst: 想知道解法+ 就算是独立开发真的会有这种问题 06/21 00:52
25F:推 gino0717: 这串文真的赞 06/21 01:02
26F:→ lywctl: 科 每次都久久出来刷一次存在感 06/21 02:26
27F:→ felixgugu: 有讲跟没讲一样 06/21 04:55
28F:推 gundam00: 根据这位乡民的程度 我猜解法应该就是一个人开发就好 06/21 06:53
29F:→ beaprayguy: 我有说小A打框架,其他人从dev clone 06/21 06:54
30F:嘘 vn509942: 如同你的表达能力一样 那三人的沟通能力也有问题 06/21 07:02
31F:→ vn509942: 工具是用来辅助解决问题 如果有问题的是使用者 06/21 07:09
32F:→ vn509942: 应该解决使用者 06/21 07:09
33F:推 beaprayguy: 另外要做什麽leader会说啊@@ 06/21 07:11
34F:→ doranako: abc都在对相同档案编辑,不打架才怪,很怪的逻辑 06/21 09:35
35F:推 NCUking: 我资质太差看不懂这篇 06/21 10:54
36F:→ NCUking: 大师能多开示一点吗 普渡众生 06/21 10:54
37F:推 Kazimir: 我觉得还是比A上传以後被B盖掉B再被C盖掉 然後问A怎麽 06/21 11:13
38F:→ Kazimir: 没修BUG好吧 不管怎麽样沟通是免不了的 06/21 11:14
39F:推 lulufufu: 这篇文的目的就是要训练各位独立思考的能力把 06/21 11:24
40F:推 hung0724: 不管用什麽版控 遇到当做 ftp 用的人都无效啦 06/21 14:00
41F:→ MOONY135: ..掯 被楼上说中了 我就是当FTP用 06/21 14:04
42F:嘘 robber1234: 工三小,怕merge错不会用rebase? 怕各做各的不会定介面 06/21 16:51
43F:→ robler: 供三小 不会用就怪工具 06/21 21:04
44F:嘘 sameber520: 你该不会想说三个人要可以不用沟通还能把东西合起来吧 06/22 00:23
45F:→ sameber520: git只能做後面这件事 不然开会开假的 06/22 00:24
46F:嘘 twin2: 方向错误的独立思考就只是一个标新立异的白痴而已喔 06/22 00:35
47F:推 Csongs: 请提出可避免人为出错的流程 06/22 12:50