V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
longway
V2EX  ›  git

真有人觉得 Git 会提高生产力?

  •  
  •   longway · 71 天前 · 16834 次点击
    这是一个创建于 71 天前的主题,其中的信息可能已经有所发展或是发生改变。
    以前一直觉得 Git 挺好。不过最近做了一个 feature,改了一大堆文件。这些文件别人也在改,有非常多 commit 。在 Git 合并,解决冲突,rebase 上花的时间远超以前用 svn/perforce/tfs 。


    看这么多人吹 git,不知道逻辑是什么,难道一个更加复杂的东西使用时会花费更少的精力?

    svn 这种中心化模式,一个人 merger 好了,其他人 sync 一下即可。现在用了 git 每个人都要管理自己的 branch,自己去做 merge 同步,真觉得这样省力?

    难道你们都是一个人在开发 ?一个冲突没有?
    第 1 条附言  ·  71 天前
    svn/perfoce/tfs 这些 10 分钟上手,所以各位用一个月也不见得精通的 git 理由是什么?
    第 2 条附言  ·  71 天前
    大家没有 get 到我的 point,关键点是使用 git 要花团队更多时间,而不是会不会用 git 的问题
    170 条回复    2021-05-27 08:31:56 +08:00
    1  2  
    iyaozhen
        101
    iyaozhen   71 天前
    没用过 svn

    这些文件别人也在改,有非常多 commit,有冲突,难道 svn 能自动解决冲突?

    git 是需要配合 git-flow 等流程的,「 svn 这种中心化模式,一个人 merger 好了,其他人 sync 一下即可」 git 一般用一个 dev 分支来解决,大家往 dev 分支合,每天持续集成

    其实个人观察来看,git 确实没有比 svn 明显的优势。但现在新人都是学的 git,用 svn 反而对团队成本大,不方便对外交流
    harryge
        102
    harryge   71 天前
    楼主可以把各个程序员的 commit history 贴出来 我敢保证你们 commit 的不是很规范 没有 squash 没有 cherry pick
    blackshow
        103
    blackshow   71 天前   ❤️ 1
    git 的好处是互不影响,合并处理在最后
    svn 如果有人功能做了一半提交了导致系统不可用直接耽误你的开发了
    auroraccc
        104
    auroraccc   71 天前
    理解你的痛苦
    1. 每次有新的 commit 之前都 rebase 一次
    2. 使用 git rerere
    dfkjgklfdjg
        105
    dfkjgklfdjg   71 天前
    只能说明你们团队不适合使用 Git 来管理多人协作
    fxxkgw
        106
    fxxkgw   71 天前   ❤️ 1
    SVN 和 git 都用过好几年 个人感觉小团队几个人情况下 SVN 好用

    没有非常深入用 git 一些功能加之早期一直用 SVN 习惯了吧的因素 感觉要我选择 我喜欢 svn 。。
    Email
        107
    Email   71 天前   ❤️ 5
    https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
    别看这是一篇很小的文章,大多数人没有养成这样的好习惯。 建议大家学习

    楼主所在公司是强制要求大家在 push 前,把 master 分支 rebase 到自己的分支上的。这样做的目的是杜绝 merge commit 的产生,从而产生网状的 commit history,不利于版本回溯和 bug 追踪。

    看看一些优秀的开源项目就知道,别人的历史有多干净了
    bk201
        108
    bk201   71 天前
    svn 不用解决冲突?没看懂逻辑。
    imycc
        109
    imycc   71 天前
    以往迭代频繁的时候,对团队成员的要求是至少每周一次,把 develop 分支合并回各自的开发分支,有冲突就解决冲突,避免开发了一个月的版本

    还没用过 svn,不过你描述的多人修改同一个文件的问题,不管用什么版本管理都需要解决冲突的吧?
    如果是 leader 要求什么主分支 commit 不要太多,那么你们应该加一下--squash 选项,gitlab 的 MR 那里也是提供这个功能的。

    不过如果整个团队都觉得用 git 太繁琐的话。。那就换回去呗。也没人逼你们用。
    imycc
        110
    imycc   71 天前
    @imycc #109
    第一句话打了一半。
    避免开发了一个月的版本产生太多冲突,增加最后合并和调整的成本。毕竟 git 只能协助你解决版本的冲突,但没法自动解决业务逻辑的冲突。
    index90
        111
    index90   71 天前   ❤️ 1
    楼主原话:svn 这种中心化模式,一个人 merger 好了,其他人 sync 一下即可。现在用了 git 每个人都要管理自己的 branch,自己去做 merge 同步,真觉得这样省力?

    一个人 merge 好了:git 里面,这个人 merge 进主干
    其他人 sync 一下即可:git 里面,其他人的 branch rebase 一下主干

    效果不是一样的吗?
    danieladu
        112
    danieladu   71 天前
    这和工具有啥关系,多人编辑多个文件,产生多个冲突那是必然事件,需要反思的不是这个工具如何如何,而是为什么你们的 leader 或者同事为什么要同时在有大量相同文件的地方做修改,本身这就增加复杂度,因为同时修改大量相同文件大概率会有逻辑冲突,可以一个 feature 一个 feature 迭代,或者同时做相关性不是很耦合的部分。如果是那种大型项目(比如大型的开源项目),避免不了大量的冲突,那就没办法了,可以时不时拉取下更新,这样也能让自己的 code 保持最新状态
    ChevalierLxc
        113
    ChevalierLxc   71 天前
    我觉得一点在于你们一个 PR 里有太多文件了,拆分着提交吧。这么多文件的变更,你们咋做 review?
    SeanGeek
        114
    SeanGeek   71 天前   ❤️ 1
    深呼吸 静下心 把 Git 文档过一遍
    xingguang
        115
    xingguang   71 天前
    这个就是传说中的白岩松体?不会吧不会吧!
    Arron2021
        116
    Arron2021   71 天前
    中不中心化跟 git 有什么关系?想中心化所有人在一个分支上开发不就行了
    doublechenpaul
        117
    doublechenpaul   71 天前
    最佳实践是一个 commit 不要写太多代码变更,分多个 commit
    samingzhong
        118
    samingzhong   71 天前 via iPhone
    我们团队接近 10 个人常常同时在同一条分支上开发,倒暂时没碰过多难搞的合并。可能是楼主团队开发的功能相互侵入性比较大?那好像就是分工的问题了……
    young1lin
        119
    young1lin   71 天前
    @Email 学到了,感谢。
    shayuvpn0001
        120
    shayuvpn0001   71 天前
    你完全可以把 git 当 svn 来用,订好流程就行,中心化和去中心化自己随便选。
    nanxiaobei
        121
    nanxiaobei   71 天前   ❤️ 1
    关于 git 优劣的讨论,twitter 上也见过一些,但在国内论坛讨论这个,走向基本就是:

    1. 你不会用
    2. 你太年轻了
    3. 你不懂
    4. 这和工具没关系

    总之,没几个人会讨论 git 🐶
    zgzb
        122
    zgzb   71 天前
    强制推送,改的时候改文件就行,省心
    herozzm
        123
    herozzm   71 天前
    一个人开发 只能起到备份的作用
    saucerman8
        124
    saucerman8   71 天前
    如果不是有强迫症,git merge 一般比 git rebase 好用,冲突也更少
    HannibaI
        125
    HannibaI   71 天前
    @Email 请教一下,这个和 merge 但是保留 commit history 有什么区别?
    ooops
        126
    ooops   71 天前
    不知道怎么吐槽,直接 block 了吧。。
    wukongkong
        127
    wukongkong   71 天前 via Android
    rebase 用错了,不是这样用的。这种涉及历史变更的,多人合作的就不能 rebase,用 merge 应该没那么多问题
    tairan2006
        128
    tairan2006   71 天前
    楼主确实不会用 git…
    xuanbg
        129
    xuanbg   71 天前
    不不不,git 冲突多是因为你们的项目结构有问题!!!讲真,我这里多人合作开发维护同一个项目好多年,极少有冲突的。所有的冲突都是因为多个人同时修改了同一个文件。而这种情况我们这里基本是不可能发生的,偶尔发生是因为头铁的新人不按规矩办事,瞎 JB 搞。
    leelz
        130
    leelz   71 天前
    @harryge 能有几个 -- rebase 就不错了。
    cassyfar
        131
    cassyfar   71 天前
    git clone/git pull
    git checkout -b your-branch
    git commit -m "msg"
    git merge mainline
    git push

    很难吗???
    star7th
        132
    star7th   71 天前
    看到附言说“关键点是使用 git 要花团队更多时间,而不是会不会用 git 的问题”,原谅我不自觉发出了笑声。就是因为你们不会规范使用版本工具,所以才花更多时间。
    我觉得你们的分工问题应该是重点关注的问题。正常的项目开发里,大家负责的模块是分开的。不应该会导致那么多 merger 。甚至应该做到极少的 merger 。像你说的,无论 svn 还是 git 都需要 merger,那估计是不正常了。分工模式可以再探索下。
    star7th
        133
    star7th   71 天前
    我上面说的不严格。应该说正常的项目开发里 merger 都是自动合并,极少需要手动解决冲突。
    akira
        134
    akira   71 天前
    冲突这种事情,感觉只要还是基于文本文件存储的开发,就没办法解决。。
    nvioue
        135
    nvioue   71 天前   ❤️ 1
    进来第一条就看到
    "
    Reply 101
    iyaozhen 4 小时 21 分钟前
    没用过 svn

    这些文件别人也在改,有非常多 commit,有冲突,难道 svn 能自动解决冲突?
    "

    哈哈哈哈哈哈哈哈哈哈哈哈 笑掉大牙, 每次这种问题总是一堆 git 脑残粉在这口水仗

    一定是你不会用!!
    我 git 怎么可能有问题!!
    svn 这种垃圾还有人用???
    junksheng
        136
    junksheng   71 天前 via Android
    ...虽然 git 也有挺多缺陷,但是真不能提高生产力的话怎么会这么多人用
    ochatokori
        137
    ochatokori   71 天前 via Android
    难道不是因为不会用才要花团队更多的时间吗,虽然学习也是要时间,但是不见得 svn 要比 git 更容易学
    mascteen
        138
    mascteen   71 天前 via Android
    @nvioue 这种东西谷歌一下就出来了,楼主矫情我们就不能矫情了,?
    Sainnhepark
        139
    Sainnhepark   71 天前 via Android
    @longway

    > 专门找人 merge,那个人会比你更懂你的代码?

    你不是自己说用 svn 开发时就有一个 merger 专门合并代码吗?这和我说的有啥区别?
    Email
        140
    Email   71 天前
    @HannibaI https://yanhaijing.com/git/2017/07/14/four-method-for-git-merge/
    这篇文章看一下,虽然都是一些老文,但是写的很好,好的思路和文献永不过时。

    区别就是一个历史是直线的干净的,另一个是产生网状的和多余的重复的 commit 信息。
    没有说绝对好的,只是绝大多数项目都不会在意这个
    chenqh
        141
    chenqh   71 天前
    @junksheng 很多人用 git,不是因为 github 用的 git 吗?
    cosmtrek
        142
    cosmtrek   71 天前
    如果大家都在频繁改一个文件,那可能你们分工有问题,或者代码结构不合理
    junksheng
        143
    junksheng   71 天前 via Android
    @chenqh 不觉得啊,都是跟着公司走
    iyaozhen
        144
    iyaozhen   71 天前
    @nvioue 你不能断章取义呀

    你看我后半段。后面入行的确实没用过 svn 。你是如何得出“svn 这种垃圾还有人用???”
    git 使用成本是高呀,当年百度 svn 切 git 费了老大的劲,为什么要切了,因为 svn 装不下了,还有很多新的工具链
    chenqh
        145
    chenqh   71 天前
    @junksheng 反正我是因为 github,
    Rheinmetal
        146
    Rheinmetal   71 天前   ❤️ 1
    组织架构和开发习惯不合适 git flow
    不要强上否则事半功倍
    palxex
        147
    palxex   71 天前
    怎么说呢。对初学者,git 上手确实比 svn 要复杂得多,以前都是专门写文档教新人合并啥的,也不知道能听懂多少。对 xml 这种东西更是几近智障(我知道这是 diff/merge 的锅,但没法说不是 git 的问题)。
    但是,说这种成本毫无必要就更扯淡了。svn 时代的合并简单是以没法轻易分支,本地没有完整存储库,甚至很多单位专门设置 merger 职位负责合并等等为对价的。完成这个迁移,尽管痛苦,但你进入的是一个更自由的世界。
    另外没用过 git flow,git 自己的工作流程搞清楚完全可以轻易地完成所有工作,甚至现在我去 clone svn 库都是走 git svn 的。
    darknoll
        148
    darknoll   71 天前
    一个文件好几个人改?
    建议请个好点的架构师吧
    ming7435
        149
    ming7435   71 天前
    从这个问题足可以看出绝大多数都是满满的优越感, 都是上来就是一顿瞎鸡儿喷.
    mauve
        150
    mauve   71 天前
    用 Git 如何改善工作效率?✖
    真有人觉得 Git 会提高生产力?✔️
    楼主提问的智慧玩到头了属于是
    rekulas
        151
    rekulas   71 天前
    你如果说 git 仍然存在不足,这是 OK 的
    你说 git 合并方便不如 svn 方便,这就是你的问题了,说明你根本没理解 git 的精髓
    svn 能实现的中心化开发 git 也能实现(通过服务器设置),但 git 的分支流模式是大项目开发的最优选择,你以为 svn 中心化开发减少了合并冲突的时间?大错特错,正以为 svn 的强制中心化合并要求,只会占用和延误开发者更多时间
    之前参与过一个数百人的跨国项目,基于 git 流程开发的非常顺畅,如果你们花在冲突的时间太多,应该考虑的是优化你们的开发工作分配而不是考虑 git 是不是比如 svn,我实在想不出 svn 相对 git 有什么特殊优势
    Felldeadbird
        152
    Felldeadbird   71 天前
    git 冲突很好解决啊。搜索<<<< 这部分代码。然后拿出 差异对比器,把 <<<< 和别人 >>> 部分 一对比,就知道哪里出错了。
    除非两个大功能一起上线,否则大多数都不需要解决很多重复冲突问题。大部分都是拿别人 >>>> 作为主要解决方案。

    SVN 有个非常不好的地方(不开分支下)。如果你的功能没上线,然后公司有人推送上去,你所有代码都被污染,等你发现怎么办?
    Felldeadbird
        153
    Felldeadbird   71 天前
    @darknoll 哈哈哈哈,说到点子上了。
    james122333
        154
    james122333   71 天前
    git 确实比较复杂 所以有人一直在问图形化工具 但如果熟悉命令行其实也还可以 这种工具到一定程度其实用起来没差很大 会基本的已经足够使用 git 就两个卖点一个分支一个本地 commit 一个分支不同实现与需求实作中然后要改其他分支的东西更崩溃 怕一不小心操作错误就重来了 这时候手动操作也未必不可
    分支多合起来能不能正常是问题没错
    youxiachai
        155
    youxiachai   71 天前   ❤️ 2
    连 git 都用不好,这团队素质有点差。。。
    tomkliyes
        156
    tomkliyes   71 天前
    标题就十分引战,你认为 git 不适合你们团队,svn 更适合,可以拿出来分享讨论。git 已经是开源社区的事实标准,我想一定是有它的优势的。你用 svn 也好,用 git 也好,都是你所在团队自己的选择
    johnsona
        157
    johnsona   71 天前 via iPhone
    确实要学习成本 之前新入职同事几乎都在 git 上遇到困难 一个功能还没搞定 先花大量时间折腾 git 工作流了
    freelancher
        158
    freelancher   71 天前
    说实话,我支持楼主。很有提问的智慧。
    bao3
        159
    bao3   71 天前 via iPhone   ❤️ 1
    我是从 svn 一路用过来,嗯,git 真的是太细致太庞杂,真的不如 svn,但是对于小朋友,他们出生后没有选择,只有 git 这个选项。就好像即墨我们当地人读了 2500 年 ji mì,但是小朋友们出生后只能选择读 ji mò。
    即使 svn 再方便再轻量,也只能使用 git
    GeruzoniAnsasu
        160
    GeruzoniAnsasu   71 天前   ❤️ 1
    @longway #76

    git 设计初衷即如此,你会发现 git 的适用场景是独立开发者一起合作写代码。如果合作不是写代码,或者团队成员并不需要保持相互独立性,git 绝大部分 feature 根本就没用。

    git 是从独立开发者们手中迭代出来的,svn 是从企业开发流程中成长出来的,这能一样吗。



    git 的缺陷是很明显的,它并不是普遍适用的版本管理工具,很多人看不见房间里的大象而已
    就跟 php 是世界上最好的语言也确实是真的有道理的,只是很多人体会不到它的伟大之处罢了
    Jeremial
        161
    Jeremial   71 天前
    如果一个人简历说 git 用的比较熟, 我会先问问他是否知道 merge 和 rebase 的区别是什么
    dk7952638
        162
    dk7952638   71 天前
    实话实说,国内 90%的团队用 svn 的用法用 git,能好用才怪。。。
    myCupOfTea
        163
    myCupOfTea   71 天前
    要中心化管理用 pr 模式不行吗
    assiadamo
        164
    assiadamo   71 天前
    svn p4 这些最大的毛病就是占空间太大了,其他倒还好
    no1xsyzy
        165
    no1xsyzy   71 天前   ❤️ 1
    我直觉地认为其实贵团队只是遭遇了常规的「软件开发焦油坑」,此概念由 FPB 在《人月神话》中提出。
    你可以试试 svn,多半是没有解决。

    至于 git,自身确实有些问题,但多半跟你遇到的问题没关系:
    0. 各种 workflow 就是在解决 git 本身的问题,其存在本身即可论证 git 有问题;
    1. git 是为了分布式开发设计的,每个人各自管理 branch 各自 merge 是 feature ;
    2. git 是为了 C 语言设计的,更精确地说,是为了 LBT 的代码格式风格的 C 设计的;
    3. 实际上最优情况下每个团队(包括一人团队)应当自己构建自己的版本管理系统,而不是用一个现成的版本管理系统(比如 SQLite 就自己造了一个版本管理系统),但因为时间或成本或能力或安于现状或多种因素融合的问题,大部分团队没能造罢了。
    vansouth
        166
    vansouth   70 天前
    典型不会用又不愿意花时间学的人````就算你不会用 一样能将 git 当 svn 用啊````
    philonic
        167
    philonic   70 天前 via Android
    @fxxkgw 我觉得恰恰相反,公司 n 多项目,开发库,过程库,受控库,n 多基于现场版本修改,产品代码库,定制代码库,git 已经远远不够用了
    yinxianwei
        168
    yinxianwei   70 天前 via iPhone
    只是不会用
    guanyinli
        169
    guanyinli   70 天前
    看来楼主没在多人团队用过 svn
    clino
        170
    clino   70 天前
    @nanxiaobei 楼主自己就不是来讨论 git 的,他是已经有结论以后来说服大家 git 不好学,劝大家不要用 git 的
    1  2  
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3758 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 02:12 · PVG 10:12 · LAX 19:12 · JFK 22:12
    ♥ Do have faith in what you're doing.