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

[longway]

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


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

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

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

[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 信息。
没有说绝对好的，只是绝大多数项目都不会在意这个