真有人觉得 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 的问题

[malusama]

你们也可以都提交到 master， 不也是一个人解决冲突么

[hwdef]

建议看看《代码奔腾》(code rush)，那时候还没有 git，要管理 firefox 的源码，很困难。

[ch2]

有尽量避免或者妥善解决这种冲突的办法

[kingzeus]

工具会不会提高生产力在于你的使用方法
建议使用前看下 git 的相关文档 /视频，不只是命令介绍，还包括了工作流模型，………………
磨刀不误砍柴工

[NEVERCODE]

对不起，我不知道你们都是提交到 master，我们都是自己拉一份，然后合并

[murmur]

git 适合于远程互不认识的人撕逼，自己一个单位有明确分工的 svn 也可以搞定，毕竟各家自扫门前雪

[kera0a]

不会用就去学啊

[66beta]

不会用就去学啊 +1

[YvesX]

中心化程度与冲突解决的繁琐程度本来就在天平的两边啊

[yEhwG10ZJa83067x]

我觉得适合那种项目模块功能分开并且清晰的项目。如果说这个项目每个人都会改相同的文件，那也太痛苦了。

[sutra]

用的什么分支模型（比如 git-flow 之类的）？

[Rwing]

我没理解，只要是多人开发就一定有冲突啊，svn 也会有冲突啊

[yungo8]

你把 git 一样可以做 svn 用，就开几条版本分支，比如 master test dev1.0 dev2.0，所有人基于一个远程分支直接 push 又不是不可以

[mekingname]

人笨怪刀钝。

[acmore]

“我用 Git 总是在解决冲突” = “我吃鱼总是被鱼刺卡嗓子”

要么你不适合吃鱼，要么你不会吃鱼，无论怎样都是正常情况。
这么简单明了的事情是没必要找认同感的。

[yousabuk]

真有人觉得炒币能赚到钱？
真有人觉得强行壁咚不会被甩巴掌？
==============================
前边的吐槽很正常，可以理解。
最后一句，就暴漏狭隘了。

[Sainnhepark]

不知道你在说什么。

你要是不想合并，那把你的分支 push 上去，然后专门找个 merger 来合并不就好了？

[cslive]

主仓库不动，自己 fork 一个，改完之后 pr，这样就应该没有问题了吧

[anyforever]

自己不研究一下自己用法有没有需要改进的地方，吐槽这个能解决什么问题？

[coderluan]

人话:

Git 并不是什么场景下都能提高生产力.

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

让我感觉并 git 并不是很多人口中那么完美, 又些场景下它会更多的精力使问题更复杂.

svn 这种中心化模式，一个人 merger 好了，其他人 sync 一下即可。现在用了 git 每个人都要管理自己的 branch，自己去做 merge 同步，有的时候并不是更省力.

如果你们是能直接接触的团队, 冲突也很多, 可以考虑不用 git.

阴阳人话:

.......

[newComingBoy]

个人觉得是你命令用错了，这种情况建议使用 merge 而不是 rebase

[Kontinue]

1. 及时更新上游分支，及时解决冲突
2. 自己的 feature 合并时没有的 commit 先 squash 一下，rebase 冲突多，选择 merge 一次性解决所有冲突

[yaphets666]

git 没好到哪去，svn 也没坏到哪去，大厂也一样出代码管理问题。

[tabris17]

这是你用法的错误，不是 git 的错误

[clino]

感觉楼主说的场景问题不在 git，而是开发模式，甚至只是代码组织和人员分工的问题

[zhaol]

不懂就问,svn 的话,同一个文件几个人同时修改难道不会冲突吗?

[DelayNoMay]

merge 很难么，用好 ide，merge 很简单

[mxT52CRuqR6o5]

没用过 svn，svn 怎么解决冲突的？

[yunye]

好歹抽空认真学学怎么用

[Jooooooooo]

git 也是一个人 merge 了其它人拉一下就同步了.

[lscho]

1.git 也可以由一个人来 merge
2.楼主这种很多人修改同一个文件的场景，用哪个工具都不会提高生产力
3.赞同 #25 说法，建议考虑一下开发模式及代码组织结构

[star7th]

内部团队用的话其实 svn 也不差。git 是一种更普适的适合各种规模的版本管理。比如开源给全世界不认识的人看以及协作。
另外你的问题不是版本管理软件的问题，纯属是你们自身使用不当。

[namelosw]

你们持续集成做得不好，master 开发小步提交，保持功能不挂，强制 rebase 再试试就没这个问题了

[yvescheung]

建议原文翻译成英文发给 Linus 看看他的想法

[pkoukk]

git 不一样么？一个人在 master 上合并好了，剩下人拉一下就行了

[Fule]

长时间不及时双向合并什么工具也救不了。任务划分导致经常几个人同时修改同一个文件也是什么工具都救不了。

[mxT52CRuqR6o5]

svn 是改了一个字就会立刻同步给所有人？你 svn 两个人都大幅度改了同一个文件后 sync 一点人工干预都不需要？

[InkAndBanner]

楼主有点傲慢 从标题和内容可见一斑 还是要虚心呀 ，也不怪楼上的那些回复

[vanxy]

遇到问题， 可以先动动脑子， 思考下下面的问题， 就不会说出这种贻笑大方的问题了

1. git 和 rebase 的本质区别是什么
2. git 中 rebase 、merge 区别是什么
3. 其他团队是如何解决冲突问题的

[nekoneko]

关键问题不在 git
关键问题在于同一个文件为什么会有多个人进行修改
说明分工不明确,或者项目不够模块化

[ayase252]

我觉得可能不是 git 的问题，可能更是项目组织的问题？

[ThisDay]

其实楼主最大的问题是 rebase 导致他觉得同一个文件虽然只冲突了一次，但因为有多个 commit 在上面的，所以每一个 commit 都需要解冲突一次

[WhoMercy]

磨刀不误砍柴工

[raaaaaar]

复杂=会降低效率？
学语言不复杂吗？学操作系统不复杂吗？学 IDE 不复杂吗？正是因为复杂，所以掌握后提高的效率才更高，就是提前打通一条路径，或者说习惯。只是掌握一次，又不是每次用都要重学。

[runinhard]

。。。。。

[lesismal]

这篇文章讲得不错：
https://www.163.com/dy/article/G9LK0LIH0511FQO9.html

[zjsxwc]

楼主这是在用 svn 的模式玩 git，svn 模式：一堆人都在同一个分支上改。

而 git 模式应该是每个 feature 一个分支。

建议楼主使用 pull request/merge request 这种 git 主流的工作方式，来解决楼主上面说的问题，而不是抱怨，没有代码 review 强行合并分支的楼主现在当然很惨了。

[JamesR]

我 Git，SVN，2 个都用，各有各好处，人少，比如 1~2 人情况下，SVN 更好用。

[deplives]

“大家没有 get 到我的 point，关键点是使用 git 要花团队更多时间，而不是会不会用 git 的问题” 这不就是一个团队的人都不会用 git 么

[tinyuu]

就用一分支吧，当 svn 用。 这玩意 有没有强制规范 团队正门方便 ，怎么效率怎么有。

[zeevin]

git 使用来管理项目代码的，前提是你的项目要拆分明确。一把快刀，屠夫能解牛，我们只能乱剁。

[yangyaofei]

版本管理本来就不是为了生产力做的, 就是为了多人协作和构建较为稳定可控的项目用的.

[auh]

整不明白就别搞了。多难受。

[zhuangzhuang1988]

说得对.

[zackkson1991]

我觉得楼主关于 git 的并没有做到最佳实践. 最后一步, 必须有人负责 review. 楼上也有朋友说到就是, 没有 review 就直接强行 merge 到 main branch 这些, 就不是最佳实践了.

[Mutoo]

典型的垃不出屎怪地心引力。

[Biwood]

昨天就是为了这个问题搞到很晚，我甚至怀疑楼主是我同事，哈哈哈…

不过我觉得不是 git 的问题，而是 rebase 的问题，我以前偶尔会用 rebase，后来遇到了一些坑就很久都不用了，能用 merge 解决的绝不 rebase，特别是改动文件比较多的时间

[liyhu]

那你说一个比 git 好的

[skull]

哈哈，一个人的能力决定了他的认知

[QlanQ]

多人同时修改同一个文件，这种问题，git 确实解决不了，有啥工具能解决？

[kikyous]

真有人觉得版本控制软件会提高生产力？
反正我是从来不用的

[shenqi]

难道你们都是一个人在开发 ？
这句话我觉得刚好反问你。

[raffaellolin]

git 大家都用不习惯 网上问问题❌ 改用 svn ✔

[IvanLi127]

你举的例子只能证明你们团队不行啊。。。。全部提交到中央仓库，一个人解决冲突后，大家再更新不就好了。

[hello2060]

支持楼主，一个团队多浪费时间啊，所有的活一个人干不就得了。

[felixcode]

接受不了新事物的心态

[yuankui]

没事你 rebase 干啥？建议你跟老大建议继续用 svn 吧，适合自己的才是最好的

[missdeer]

get 到你的点了，但你的点前提是错的，在错的前提下讨论再多也没意义

[est]

我觉得大家都让 LZ 去学或者看书，这种是无助于讨论的。

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

其实 git 就是这样用的。每个人管理自己的 branch 可能是 LZ 走偏了。

[longway]

@Biwood

为了减少 master 的 commit，每个人都会在自己的 branch 上先 rebase 一下。

[longway]

@Sainnhepark

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

[h82258652]

别的不说，至少我觉得 svn 有两个地方是远远不如 git 的。
1 、分支，svn 的分支就是 copy 一份，每开一个分支，repo 体积多一倍。我们用 git 每发一个生产环境版本都要打一个 tag 的，svn 这样的分支设计难以支持；
2 、缺少 gitignore 对应的实现，这个在 svn 里要不就只能全局设置，不能对应到单独的 repo 上面，然而事实就是每个 repo 要 ignore 的确实不一样。最后结果就是 svn 的 repo 就提交了一堆没用的文件，包括代码编译生成的二进制文件，进一步导致了第一点问题的加剧。

[longway]

@mxT52CRuqR6o5

perfoce/svn 大家会共用一个开发 branch，提交每一个 commit 前做冲突解决，开发前自己先拉下代码即可，从来没觉得代码同步、提交、合并会是个问题。而不像 GIT，等各人开发 一段时间，冲突已经积累一大堆。

[jones2000]

流程有问题吧. 每个人负责一个模块, 每个模块都是独立的文件, 一般不会多个人改同一个文件的.

[fiypig]

只要分配各个模块，就不太会出现这个问题，除非是改到一些公共模块．．．

[longway]

@jones2000

所以 git 更适合个人独立开发各自的功能，只不是团队合作开发一个功能。

[Biwood]

@longway

取决于“减少 master 的 commit”这条原则有多重要了，感觉还是要看应用场景吧，有些场景下只能做适当的妥协

[fffang]

@longway 不要直接 rebase branch，在自己的分支上用 rebase 将 commit 压缩成一个再 merge，这样 commit 只会是一个，也不需要一个一个进行 rebase 操作

[masterclock]

@longway 使用 git，必须得 ”等各人开发 一段时间，冲突已经积累一大堆“ 之后再提交？

[jones2000]

@longway 团队合作也不需要多个人开发 1 个模块吧， 如果是一般都是构架有问题， 继续拆模块， 把这个大模块拆成小模块，1 个人能做的那种，这样开发才能平行， 否则 1 个模块 N 个人做， 上一个人功能要等下一个人开发好， 才能继续开发， 还如果 1 个人做呢。 团队开发就为了提高效率， 比如 1 个项目你 1 个人需要做 1 个星期， 那老板直接说我给你 7 个人， 你 1 天时间给我开发完。

[guog]

@longway #76 linux 内核多少人合作开发？

[neptuno]

感觉是你们团队沟通问题吧，，，这个啥工具也救不了你

[ipwx]

1. 你得用 branch 。branch 功能特别爽，每个人独立开发个把月，最后合并就行了。
2. 如果你们不能用 (1) 的方法工作，说明你们团队每个人的功能划分太奇怪了。哪有这么多的一起修改同一个文件的情况啊？这哪种工具都高效不起来啊喂。你们得有分组分层责任划分，每个组每个层和别的层除了接口其他互不相关才行啊。

[yyfearth]

用过 svn/perfoce
当有 branch 的时候 而且差别很大的情况下 根本没办法 merge
只能一个个文件重新改

这样比 git 还难受呀

如果 svn/perfoce 只用 chunk 的话 就喝 git 只用 master 一样啊 都很简单的

[ipwx]

@masterclock @jones2000 所以就是楼主 @longway 团队的合作方式有问题啊。如果每天都有大量 conflict，说明根本没有进行团队工作切分，都是临时给人派任务。。。。这妥妥的缺少个架构师

[cco]

不知道是不是我不会用 git，我们提交代码的要求，第一不能积累太多内容，最好改一个 bug 合并一次。第二，合并完必须可运行。另外，大家都按照模块来开发，交叉开发不多见。
所以到目前为止，几乎很少会出现冲突，每天写代码前先 pull，然后再开始写，及时合并，及时 pull 。

[junnplus]

看到楼上的回复我就放心了

[ipwx]

@longway 高效的大项目（也是 git 适合的场景）：每个组负责不同的子系统、组内每个人负责不同的子模块。每个人负责的文件都不一样，哪来的冲突机会？组和组之间的接口由总架构师协调，组内由组长协调。架构师干嘛的？不就是干这个的吗？

你一坨浆糊当然一直冲突…… 而且还没法开发更大的项目。

[ericgui]

如果你们经常出现 conflict，那是你们领导出问题了，而不是 git 的问题

不管用什么工具，最后还是人来用，而众所周知，蠢人居多

[Nielsen]

开发流程的问题吧，就算是 SVN，你 merge 的时候一样也要改别人的代码（如果有冲突），只不过相当于大家都要等你 merge 完再 sync 。
换到 git，你也可以吼一声大家都别动，等你 merge 完都 pull 一下。
只不过牺牲了客户端的自由度，换取了对 commit 的绝对掌控。

[balabalaguguji]

两个工具各有优缺点，个人比较喜欢 SVN，简单但是足够应付各种工作

[5200]

其实 GIT 在一些需要特定版本的项目中很方便。
觉得难用可能是没有使用到 git 的精髓，版本分支这块。或者一些场景 git 有更好的解决方案。
比如有一块大的功能，你开发完了，但是不急着上线，又有新功能模块需要开发上线，这时候使用 SVN 处理就会比较麻烦。
或者线上某个版本出问题了，要你马上回滚到特定的版本。此时一些新功能已经开发了一大块，且提交上去了。使用 SVN 也会比较麻烦。GIT 的话可以每个大版本都生成一个分支。

可以百度看一些 GIT 应用场景之类的文章，会有所收获。

http://www.ruanyifeng.com/blog/2015/08/git-use-process.html
https://juejin.cn/post/6844903635533594632

[xFrye]

工具是有适用范围的，我觉得你们内部团队管理出现的问题更大。。。

[christin]

所以为什么不用 merge 要用 rebase ？

[mxT52CRuqR6o5]

@longway 你说的这些 git 也可以做到啊，很多团队用 git 的方式就是在一个分支上开发，这是项目管理者自己选择的问题，而不是 git 的问题

[serge001]

你说的这些问题跟 git 有关系么?用 svn 几个人改一个文件也一样会有冲突

[clf]

项目管理者的问题，而不是 git 的问题。

[Dlad]

真有人觉得 8 车道大马路会提高生产力？
以前一直觉得大马路很好，不过最近需要到马路对面去。其他人也要去，人和车都非常多，等红灯的时间远超以前走乡间小路。
看这么多人吹村村通，不知道逻辑是什么，难道一个更加复杂的东西使用时会花费更少的精力？

[imkerberos]

楼主太年轻, 没用过 CVS.

[securityCoding]

没事用 rebase 干嘛...