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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 1284 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

第 1 条附言 · 2021-05-25 11:40:49 +08:00

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

第 2 条附言 · 2021-05-25 11:42:30 +08:00

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

170 条回复 • 2021-05-27 08:31:56 +08:00

1 2

❮

❯

101

iyaozhen

2021-05-25 14:55:58 +08:00

没用过 svn

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

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

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

102

harryge

2021-05-25 14:57:17 +08:00

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

103

blackshow

2021-05-25 15:02:21 +08:00

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

104

auroraccc

2021-05-25 15:08:06 +08:00

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

105

dfkjgklfdjg

2021-05-25 15:08:16 +08:00

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

106

fxxkgw

2021-05-25 15:09:29 +08:00

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

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

107

Email

2021-05-25 15:12:55 +08:00

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

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

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

108

bk201

2021-05-25 15:20:11 +08:00

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

109

imycc

2021-05-25 15:26:24 +08:00

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

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

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

110

imycc

2021-05-25 15:28:32 +08:00

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

111

index90

2021-05-25 15:34:35 +08:00

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

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

效果不是一样的吗？

112

danieladu

2021-05-25 15:34:43 +08:00

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

113

ChevalierLxc

2021-05-25 15:36:14 +08:00

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

114

SeanGeek

2021-05-25 15:37:21 +08:00

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

115

xingguang

2021-05-25 15:40:31 +08:00

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

116

Arron2021

2021-05-25 15:50:01 +08:00

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

117

doublechenpaul

2021-05-25 15:55:41 +08:00

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

118

samingzhong

2021-05-25 16:02:06 +08:00 via iPhone

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

119

young1lin

2021-05-25 16:02:59 +08:00

@Email 学到了，感谢。

120

shayuvpn0001

2021-05-25 16:06:40 +08:00

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

121

nanxiaobei

2021-05-25 16:17:12 +08:00

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

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

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

122

zgzb

2021-05-25 16:24:55 +08:00

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

123

herozzm

2021-05-25 16:29:52 +08:00

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

124

saucerman8

2021-05-25 16:31:37 +08:00

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

125

HannibaI

2021-05-25 16:42:10 +08:00

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

126

ooops

2021-05-25 16:49:32 +08:00

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

127

wukongkong

2021-05-25 16:59:35 +08:00 via Android

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

128

tairan2006

2021-05-25 17:11:47 +08:00

楼主确实不会用 git…

129

xuanbg

2021-05-25 17:20:33 +08:00

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

130

leelz

2021-05-25 17:34:29 +08:00

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

131

cassyfar

2021-05-25 17:42:13 +08:00

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

很难吗？？？

132

star7th

2021-05-25 18:10:59 +08:00

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

133

star7th

2021-05-25 18:12:17 +08:00

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

134

akira

2021-05-25 18:20:14 +08:00

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

135

nvioue

2021-05-25 19:18:53 +08:00

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

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

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

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

136

junksheng

2021-05-25 19:29:20 +08:00 via Android

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

137

ochatokori

2021-05-25 19:29:48 +08:00 via Android

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

138

mascteen

2021-05-25 19:33:49 +08:00 via Android

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

139

Sainnhepark

2021-05-25 19:37:50 +08:00 via Android

@longway

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

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

140

Email

2021-05-25 19:38:48 +08:00

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

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

141

chenqh

2021-05-25 19:44:00 +08:00

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

142

cosmtrek

2021-05-25 19:47:53 +08:00

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

143

junksheng

2021-05-25 19:52:39 +08:00 via Android

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

144

iyaozhen

2021-05-25 20:00:40 +08:00

@nvioue 你不能断章取义呀

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

145

chenqh

2021-05-25 20:07:38 +08:00

@junksheng 反正我是因为 github,

146

Rheinmetal

2021-05-25 20:16:39 +08:00

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

147

palxex

2021-05-25 20:55:43 +08:00

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

148

darknoll

2021-05-25 21:18:53 +08:00

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

149

ming7435

2021-05-25 21:25:42 +08:00

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

150

mauve

2021-05-25 21:33:07 +08:00

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

151

rekulas

2021-05-25 21:43:31 +08:00

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

152

Felldeadbird

2021-05-25 21:52:16 +08:00

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

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

153

Felldeadbird

2021-05-25 21:54:09 +08:00

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

154

james122333

2021-05-25 22:02:57 +08:00

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

155

youxiachai

2021-05-25 22:20:15 +08:00

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

156

tomkliyes

2021-05-25 22:36:26 +08:00

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

157

johnsona

2021-05-26 00:27:29 +08:00 via iPhone

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

158

freelancher

2021-05-26 01:01:24 +08:00

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

159

bao3

2021-05-26 06:51:35 +08:00 via iPhone

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

160

GeruzoniAnsasu

2021-05-26 07:03:00 +08:00

@longway #76

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

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

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

161

Jeremial

2021-05-26 08:59:56 +08:00

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

162

dk7952638

2021-05-26 09:24:32 +08:00

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

163

myCupOfTea

2021-05-26 09:59:01 +08:00

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

164

assiadamo

2021-05-26 10:03:33 +08:00

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

165

no1xsyzy

2021-05-26 10:06:03 +08:00

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

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