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

[longway]

以前一直觉得 Git 挺好。不过最近做了一个 feature，改了一大堆文件。这些文件别人也在改，有非常多 commit 。在 Git 合并，解决冲突,rebase 上花的时间远超以前用 svn/perforce/tfs 。


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

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

难道你们都是一个人在开发 ？一个冲突没有？

svn/perfoce/tfs 这些 10 分钟上手，所以各位用一个月也不见得精通的 git 理由是什么？

大家没有 get 到我的 point，关键点是使用 git 要花团队更多时间，而不是会不会用 git 的问题

[iyaozhen]

没用过 svn

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

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

其实个人观察来看，git 确实没有比 svn 明显的优势。但现在新人都是学的 git，用 svn 反而对团队成本大，不方便对外交流

[harryge]

楼主可以把各个程序员的 commit history 贴出来 我敢保证你们 commit 的不是很规范 没有 squash 没有 cherry pick

[blackshow]

git 的好处是互不影响，合并处理在最后
svn 如果有人功能做了一半提交了导致系统不可用直接耽误你的开发了

[auroraccc]

理解你的痛苦
1. 每次有新的 commit 之前都 rebase 一次
2. 使用 git rerere

[dfkjgklfdjg]

只能说明你们团队不适合使用 Git 来管理多人协作

[fxxkgw]

SVN 和 git 都用过好几年 个人感觉小团队几个人情况下 SVN 好用

没有非常深入用 git 一些功能加之早期一直用 SVN 习惯了吧的因素 感觉要我选择 我喜欢 svn 。。

[Email]

https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
别看这是一篇很小的文章，大多数人没有养成这样的好习惯。 建议大家学习

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

看看一些优秀的开源项目就知道，别人的历史有多干净了

[bk201]

svn 不用解决冲突？没看懂逻辑。

[imycc]

以往迭代频繁的时候，对团队成员的要求是至少每周一次，把 develop 分支合并回各自的开发分支，有冲突就解决冲突，避免开发了一个月的版本

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

不过如果整个团队都觉得用 git 太繁琐的话。。那就换回去呗。也没人逼你们用。

[imycc]

@imycc #109
第一句话打了一半。
避免开发了一个月的版本产生太多冲突，增加最后合并和调整的成本。毕竟 git 只能协助你解决版本的冲突，但没法自动解决业务逻辑的冲突。

[index90]

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

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

效果不是一样的吗？

[danieladu]

这和工具有啥关系，多人编辑多个文件，产生多个冲突那是必然事件，需要反思的不是这个工具如何如何，而是为什么你们的 leader 或者同事为什么要同时在有大量相同文件的地方做修改，本身这就增加复杂度，因为同时修改大量相同文件大概率会有逻辑冲突，可以一个 feature 一个 feature 迭代，或者同时做相关性不是很耦合的部分。如果是那种大型项目（比如大型的开源项目），避免不了大量的冲突，那就没办法了，可以时不时拉取下更新，这样也能让自己的 code 保持最新状态

[ChevalierLxc]

我觉得一点在于你们一个 PR 里有太多文件了，拆分着提交吧。这么多文件的变更,你们咋做 review?

[SeanGeek]

深呼吸 静下心 把 Git 文档过一遍

[xingguang]

这个就是传说中的白岩松体？不会吧不会吧！

[Arron2021]

中不中心化跟 git 有什么关系？想中心化所有人在一个分支上开发不就行了

[doublechenpaul]

最佳实践是一个 commit 不要写太多代码变更，分多个 commit

[samingzhong]

我们团队接近 10 个人常常同时在同一条分支上开发，倒暂时没碰过多难搞的合并。可能是楼主团队开发的功能相互侵入性比较大？那好像就是分工的问题了……

[young1lin]

@Email 学到了，感谢。

[shayuvpn0001]

你完全可以把 git 当 svn 来用，订好流程就行，中心化和去中心化自己随便选。

[nanxiaobei]

关于 git 优劣的讨论，twitter 上也见过一些，但在国内论坛讨论这个，走向基本就是：

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

总之，没几个人会讨论 git 🐶

[zgzb]

强制推送，改的时候改文件就行，省心

[herozzm]

一个人开发 只能起到备份的作用

[saucerman8]

如果不是有强迫症，git merge 一般比 git rebase 好用，冲突也更少

[HannibaI]

@Email 请教一下，这个和 merge 但是保留 commit history 有什么区别？

[ooops]

不知道怎么吐槽，直接 block 了吧。。

[wukongkong]

rebase 用错了，不是这样用的。这种涉及历史变更的，多人合作的就不能 rebase，用 merge 应该没那么多问题

[tairan2006]

楼主确实不会用 git…

[xuanbg]

不不不，git 冲突多是因为你们的项目结构有问题！！！讲真，我这里多人合作开发维护同一个项目好多年，极少有冲突的。所有的冲突都是因为多个人同时修改了同一个文件。而这种情况我们这里基本是不可能发生的，偶尔发生是因为头铁的新人不按规矩办事，瞎 JB 搞。

[leelz]

@harryge 能有几个 -- rebase 就不错了。

[cassyfar]

git clone/git pull
git checkout -b your-branch
git commit -m "msg"
git merge mainline
git push

很难吗？？？

[star7th]

看到附言说“关键点是使用 git 要花团队更多时间，而不是会不会用 git 的问题”，原谅我不自觉发出了笑声。就是因为你们不会规范使用版本工具，所以才花更多时间。
我觉得你们的分工问题应该是重点关注的问题。正常的项目开发里，大家负责的模块是分开的。不应该会导致那么多 merger 。甚至应该做到极少的 merger 。像你说的，无论 svn 还是 git 都需要 merger，那估计是不正常了。分工模式可以再探索下。

[star7th]

我上面说的不严格。应该说正常的项目开发里 merger 都是自动合并，极少需要手动解决冲突。

[akira]

冲突这种事情，感觉只要还是基于文本文件存储的开发，就没办法解决。。

[nvioue]

进来第一条就看到
"
Reply 101
iyaozhen 4 小时 21 分钟前
没用过 svn

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

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

一定是你不会用!!
我 git 怎么可能有问题!!
svn 这种垃圾还有人用???

[junksheng]

...虽然 git 也有挺多缺陷，但是真不能提高生产力的话怎么会这么多人用

[ochatokori]

难道不是因为不会用才要花团队更多的时间吗，虽然学习也是要时间，但是不见得 svn 要比 git 更容易学

[mascteen]

@nvioue 这种东西谷歌一下就出来了，楼主矫情我们就不能矫情了，？

[Sainnhepark]

@longway

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

你不是自己说用 svn 开发时就有一个 merger 专门合并代码吗？这和我说的有啥区别？

[Email]

@HannibaI https://yanhaijing.com/git/2017/07/14/four-method-for-git-merge/
这篇文章看一下，虽然都是一些老文，但是写的很好，好的思路和文献永不过时。

区别就是一个历史是直线的干净的，另一个是产生网状的和多余的重复的 commit 信息。
没有说绝对好的，只是绝大多数项目都不会在意这个

[chenqh]

@junksheng 很多人用 git,不是因为 github 用的 git 吗?

[cosmtrek]

如果大家都在频繁改一个文件，那可能你们分工有问题，或者代码结构不合理

[junksheng]

@chenqh 不觉得啊，都是跟着公司走

[iyaozhen]

@nvioue 你不能断章取义呀

你看我后半段。后面入行的确实没用过 svn 。你是如何得出“svn 这种垃圾还有人用???”
git 使用成本是高呀，当年百度 svn 切 git 费了老大的劲，为什么要切了，因为 svn 装不下了，还有很多新的工具链

[chenqh]

@junksheng 反正我是因为 github,

[Rheinmetal]

组织架构和开发习惯不合适 git flow
不要强上否则事半功倍

[palxex]

怎么说呢。对初学者，git 上手确实比 svn 要复杂得多，以前都是专门写文档教新人合并啥的，也不知道能听懂多少。对 xml 这种东西更是几近智障（我知道这是 diff/merge 的锅，但没法说不是 git 的问题）。
但是，说这种成本毫无必要就更扯淡了。svn 时代的合并简单是以没法轻易分支，本地没有完整存储库，甚至很多单位专门设置 merger 职位负责合并等等为对价的。完成这个迁移，尽管痛苦，但你进入的是一个更自由的世界。
另外没用过 git flow，git 自己的工作流程搞清楚完全可以轻易地完成所有工作，甚至现在我去 clone svn 库都是走 git svn 的。

[darknoll]

一个文件好几个人改？
建议请个好点的架构师吧

[ming7435]

从这个问题足可以看出绝大多数都是满满的优越感, 都是上来就是一顿瞎鸡儿喷.

[mauve]

用 Git 如何改善工作效率？✖
真有人觉得 Git 会提高生产力？✔️
楼主提问的智慧玩到头了属于是

[rekulas]

你如果说 git 仍然存在不足，这是 OK 的
你说 git 合并方便不如 svn 方便，这就是你的问题了，说明你根本没理解 git 的精髓
svn 能实现的中心化开发 git 也能实现(通过服务器设置)，但 git 的分支流模式是大项目开发的最优选择，你以为 svn 中心化开发减少了合并冲突的时间？大错特错，正以为 svn 的强制中心化合并要求，只会占用和延误开发者更多时间
之前参与过一个数百人的跨国项目，基于 git 流程开发的非常顺畅，如果你们花在冲突的时间太多，应该考虑的是优化你们的开发工作分配而不是考虑 git 是不是比如 svn，我实在想不出 svn 相对 git 有什么特殊优势

[Felldeadbird]

git 冲突很好解决啊。搜索<<<< 这部分代码。然后拿出 差异对比器，把 <<<< 和别人 >>> 部分 一对比，就知道哪里出错了。
除非两个大功能一起上线，否则大多数都不需要解决很多重复冲突问题。大部分都是拿别人 >>>> 作为主要解决方案。

SVN 有个非常不好的地方（不开分支下）。如果你的功能没上线，然后公司有人推送上去，你所有代码都被污染，等你发现怎么办？

[Felldeadbird]

@darknoll 哈哈哈哈，说到点子上了。

[james122333]

git 确实比较复杂 所以有人一直在问图形化工具 但如果熟悉命令行其实也还可以 这种工具到一定程度其实用起来没差很大 会基本的已经足够使用 git 就两个卖点一个分支一个本地 commit 一个分支不同实现与需求实作中然后要改其他分支的东西更崩溃 怕一不小心操作错误就重来了 这时候手动操作也未必不可
分支多合起来能不能正常是问题没错

[youxiachai]

连 git 都用不好，这团队素质有点差。。。

[tomkliyes]

标题就十分引战，你认为 git 不适合你们团队，svn 更适合，可以拿出来分享讨论。git 已经是开源社区的事实标准，我想一定是有它的优势的。你用 svn 也好，用 git 也好，都是你所在团队自己的选择

[johnsona]

确实要学习成本 之前新入职同事几乎都在 git 上遇到困难 一个功能还没搞定 先花大量时间折腾 git 工作流了

[freelancher]

说实话，我支持楼主。很有提问的智慧。

[bao3]

我是从 svn 一路用过来，嗯，git 真的是太细致太庞杂，真的不如 svn，但是对于小朋友，他们出生后没有选择，只有 git 这个选项。就好像即墨我们当地人读了 2500 年 ji mì，但是小朋友们出生后只能选择读 ji mò。
即使 svn 再方便再轻量，也只能使用 git

[GeruzoniAnsasu]

@longway #76

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

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



git 的缺陷是很明显的，它并不是普遍适用的版本管理工具，很多人看不见房间里的大象而已
就跟 php 是世界上最好的语言也确实是真的有道理的，只是很多人体会不到它的伟大之处罢了

[Jeremial]

如果一个人简历说 git 用的比较熟, 我会先问问他是否知道 merge 和 rebase 的区别是什么

[dk7952638]

实话实说,国内 90%的团队用 svn 的用法用 git，能好用才怪。。。

[myCupOfTea]

要中心化管理用 pr 模式不行吗

[assiadamo]

svn p4 这些最大的毛病就是占空间太大了，其他倒还好

[no1xsyzy]

我直觉地认为其实贵团队只是遭遇了常规的「软件开发焦油坑」，此概念由 FPB 在《人月神话》中提出。
你可以试试 svn，多半是没有解决。

至于 git，自身确实有些问题，但多半跟你遇到的问题没关系：
0. 各种 workflow 就是在解决 git 本身的问题，其存在本身即可论证 git 有问题；
1. git 是为了分布式开发设计的，每个人各自管理 branch 各自 merge 是 feature ；
2. git 是为了 C 语言设计的，更精确地说，是为了 LBT 的代码格式风格的 C 设计的；
3. 实际上最优情况下每个团队（包括一人团队）应当自己构建自己的版本管理系统，而不是用一个现成的版本管理系统（比如 SQLite 就自己造了一个版本管理系统），但因为时间或成本或能力或安于现状或多种因素融合的问题，大部分团队没能造罢了。

[vansouth]

典型不会用又不愿意花时间学的人````就算你不会用 一样能将 git 当 svn 用啊````

[philonic]

@fxxkgw 我觉得恰恰相反，公司 n 多项目，开发库，过程库，受控库，n 多基于现场版本修改，产品代码库，定制代码库，git 已经远远不够用了

[yinxianwei]

只是不会用

[guanyinli]

看来楼主没在多人团队用过 svn

[clino]

@nanxiaobei 楼主自己就不是来讨论 git 的，他是已经有结论以后来说服大家 git 不好学，劝大家不要用 git 的