 |
malusamaMay 25, 2021
1
你们也可以都提交到 master， 不也是一个人解决冲突么
|
 |
2
建议看看《代码奔腾》(code rush)，那时候还没有 git，要管理 firefox 的源码，很困难。
|
 |
ch2May 25, 2021
3
有尽量避免或者妥善解决这种冲突的办法
|
 |
4
工具会不会提高生产力在于你的使用方法
建议使用前看下 git 的相关文档 /视频，不只是命令介绍，还包括了工作流模型，……………… 磨刀不误砍柴工 |
 |
NEVERCODEMay 25, 2021
5
对不起，我不知道你们都是提交到 master，我们都是自己拉一份，然后合并
|
 |
6
git 适合于远程互不认识的人撕逼，自己一个单位有明确分工的 svn 也可以搞定，毕竟各家自扫门前雪
|
 |
7
不会用就去学啊
|
 |
66betaMay 25, 2021
8
不会用就去学啊 +1
|
 |
YvesXMay 25, 2021
9
中心化程度与冲突解决的繁琐程度本来就在天平的两边啊
|
 |
yEhwG10ZJa83067xMay 25, 2021
10
我觉得适合那种项目模块功能分开并且清晰的项目。如果说这个项目每个人都会改相同的文件，那也太痛苦了。
|
 |
sutraMay 25, 2021
11
用的什么分支模型（比如 git-flow 之类的）？
|
 |
RwingMay 25, 2021
12
我没理解，只要是多人开发就一定有冲突啊，svn 也会有冲突啊
|
 |
yungo8May 25, 2021 via Android
13
你把 git 一样可以做 svn 用，就开几条版本分支，比如 master test dev1.0 dev2.0，所有人基于一个远程分支直接 push 又不是不可以
|
 |
14
人笨怪刀钝。
|
 |
15
“我用 Git 总是在解决冲突” = “我吃鱼总是被鱼刺卡嗓子”
要么你不适合吃鱼，要么你不会吃鱼，无论怎样都是正常情况。 这么简单明了的事情是没必要找认同感的。 |
 |
yousabukMay 25, 2021 via iPhone
16
真有人觉得炒币能赚到钱？
真有人觉得强行壁咚不会被甩巴掌？ ============================== 前边的吐槽很正常，可以理解。 最后一句，就暴漏狭隘了。 |
 |
SainnheparkMay 25, 2021 via Android
17
不知道你在说什么。
你要是不想合并，那把你的分支 push 上去，然后专门找个 merger 来合并不就好了？ |
 |
csliveMay 25, 2021
18
主仓库不动，自己 fork 一个，改完之后 pr，这样就应该没有问题了吧
|
 |
anyforeverMay 25, 2021
19
自己不研究一下自己用法有没有需要改进的地方，吐槽这个能解决什么问题？
|
 |
20
人话:
Git 并不是什么场景下都能提高生产力. 以前一直觉得 Git 挺好。不过最近做了一个 feature，改了一大堆文件。这些文件别人也在改，有非常多 commit 。在 Git 合并，解决冲突,rebase 上花的时间远超以前用 svn/perforce/tfs 。 让我感觉并 git 并不是很多人口中那么完美, 又些场景下它会更多的精力使问题更复杂. svn 这种中心化模式，一个人 merger 好了，其他人 sync 一下即可。现在用了 git 每个人都要管理自己的 branch，自己去做 merge 同步，有的时候并不是更省力. 如果你们是能直接接触的团队, 冲突也很多, 可以考虑不用 git. 阴阳人话: ....... |
 |
newComingBoyMay 25, 2021
21
个人觉得是你命令用错了，这种情况建议使用 merge 而不是 rebase
|
 |
KontinueMay 25, 2021
22
1. 及时更新上游分支，及时解决冲突
2. 自己的 feature 合并时没有的 commit 先 squash 一下，rebase 冲突多，选择 merge 一次性解决所有冲突 |
 |
yaphets666May 25, 2021
23
git 没好到哪去，svn 也没坏到哪去，大厂也一样出代码管理问题。
|
 |
tabris17May 25, 2021
24
这是你用法的错误，不是 git 的错误
|
 |
25
感觉楼主说的场景问题不在 git，而是开发模式，甚至只是代码组织和人员分工的问题
|
 |
zhaolMay 25, 2021
26
不懂就问,svn 的话,同一个文件几个人同时修改难道不会冲突吗?
|
 |
DelayNoMayMay 25, 2021
27
merge 很难么，用好 ide，merge 很简单
|
 |
mxT52CRuqR6o5May 25, 2021
28
没用过 svn，svn 怎么解决冲突的？
|
 |
yunyeMay 25, 2021
29
好歹抽空认真学学怎么用
|
 |
JoooooooooMay 25, 2021
30
git 也是一个人 merge 了其它人拉一下就同步了.
|
 |
lschoMay 25, 2021
31
1.git 也可以由一个人来 merge
2.楼主这种很多人修改同一个文件的场景，用哪个工具都不会提高生产力 3.赞同 #25 说法，建议考虑一下开发模式及代码组织结构 |
 |
star7thMay 25, 2021
32
内部团队用的话其实 svn 也不差。git 是一种更普适的适合各种规模的版本管理。比如开源给全世界不认识的人看以及协作。
另外你的问题不是版本管理软件的问题，纯属是你们自身使用不当。 |
 |
nameloswMay 25, 2021
33
你们持续集成做得不好，master 开发小步提交，保持功能不挂，强制 rebase 再试试就没这个问题了
|
 |
yvescheungMay 25, 2021
34
建议原文翻译成英文发给 Linus 看看他的想法
|
 |
pkoukkMay 25, 2021
35
git 不一样么？一个人在 master 上合并好了，剩下人拉一下就行了
|
 |
FuleMay 25, 2021
36
长时间不及时双向合并什么工具也救不了。任务划分导致经常几个人同时修改同一个文件也是什么工具都救不了。
|
|
mxT52CRuqR6o5May 25, 2021
37
svn 是改了一个字就会立刻同步给所有人？你 svn 两个人都大幅度改了同一个文件后 sync 一点人工干预都不需要？
|
 |
InkAndBannerMay 25, 2021
38
楼主有点傲慢 从标题和内容可见一斑 还是要虚心呀 ，也不怪楼上的那些回复
|
 |
vanxyMay 25, 2021
39
遇到问题， 可以先动动脑子， 思考下下面的问题， 就不会说出这种贻笑大方的问题了
1. git 和 rebase 的本质区别是什么 2. git 中 rebase 、merge 区别是什么 3. 其他团队是如何解决冲突问题的 |
 |
nekonekoMay 25, 2021
40
关键问题不在 git
关键问题在于同一个文件为什么会有多个人进行修改 说明分工不明确,或者项目不够模块化 |
 |
ayase252May 25, 2021
41
我觉得可能不是 git 的问题，可能更是项目组织的问题？
|
 |
ThisDayMay 25, 2021
42
其实楼主最大的问题是 rebase 导致他觉得同一个文件虽然只冲突了一次，但因为有多个 commit 在上面的，所以每一个 commit 都需要解冲突一次
|
 |
WhoMercyMay 25, 2021
43
磨刀不误砍柴工
|
 |
raaaaaarMay 25, 2021 via Android
44
复杂=会降低效率？
学语言不复杂吗？学操作系统不复杂吗？学 IDE 不复杂吗？正是因为复杂，所以掌握后提高的效率才更高，就是提前打通一条路径，或者说习惯。只是掌握一次，又不是每次用都要重学。 |
 |
runinhardMay 25, 2021
45
。。。。。
|
 |
lesismalMay 25, 2021
46
|
 |
zjsxwcMay 25, 2021
47
楼主这是在用 svn 的模式玩 git，svn 模式：一堆人都在同一个分支上改。
而 git 模式应该是每个 feature 一个分支。 建议楼主使用 pull request/merge request 这种 git 主流的工作方式，来解决楼主上面说的问题，而不是抱怨，没有代码 review 强行合并分支的楼主现在当然很惨了。 |
 |
JamesRMay 25, 2021
48
我 Git，SVN，2 个都用，各有各好处，人少，比如 1~2 人情况下，SVN 更好用。
|
 |
deplivesMay 25, 2021 via iPhone
49
“大家没有 get 到我的 point，关键点是使用 git 要花团队更多时间，而不是会不会用 git 的问题” 这不就是一个团队的人都不会用 git 么
|
 |
tinyuuMay 25, 2021
50
就用一分支吧，当 svn 用。 这玩意 有没有强制规范 团队正门方便 ，怎么效率怎么有。
|
 |
zeevinMay 25, 2021
51
git 使用来管理项目代码的，前提是你的项目要拆分明确。一把快刀，屠夫能解牛，我们只能乱剁。
|
 |
yangyaofeiMay 25, 2021
52
版本管理本来就不是为了生产力做的, 就是为了多人协作和构建较为稳定可控的项目用的.
|
 |
auhMay 25, 2021
53
整不明白就别搞了。多难受。
|
 |
zhuangzhuang1988May 25, 2021
54
说得对.
|
 |
zackkson1991May 25, 2021
55
我觉得楼主关于 git 的并没有做到最佳实践. 最后一步, 必须有人负责 review. 楼上也有朋友说到就是, 没有 review 就直接强行 merge 到 main branch 这些, 就不是最佳实践了.
|
 |
MutooMay 25, 2021
56
典型的垃不出屎怪地心引力。
|
 |
BiwoodMay 25, 2021 via iPhone
57
昨天就是为了这个问题搞到很晚，我甚至怀疑楼主是我同事，哈哈哈…
不过我觉得不是 git 的问题，而是 rebase 的问题，我以前偶尔会用 rebase，后来遇到了一些坑就很久都不用了，能用 merge 解决的绝不 rebase，特别是改动文件比较多的时间 |
 |
liyhuMay 25, 2021
58
那你说一个比 git 好的
|
 |
skullMay 25, 2021
59
哈哈，一个人的能力决定了他的认知
|
 |
QlanQMay 25, 2021
60
多人同时修改同一个文件，这种问题，git 确实解决不了，有啥工具能解决？
|
 |
kikyousMay 25, 2021
61
真有人觉得版本控制软件会提高生产力？
反正我是从来不用的 |
 |
shenqiMay 25, 2021
62
难道你们都是一个人在开发 ？
这句话我觉得刚好反问你。 |
 |
raffaellolinMay 25, 2021
63
git 大家都用不习惯 网上问问题❌ 改用 svn ✔
|
 |
IvanLi127May 25, 2021 via Android
64
你举的例子只能证明你们团队不行啊。。。。全部提交到中央仓库，一个人解决冲突后，大家再更新不就好了。
|
 |
hello2060May 25, 2021
65
支持楼主，一个团队多浪费时间啊，所有的活一个人干不就得了。
|
 |
66
接受不了新事物的心态
|
 |
yuankuiMay 25, 2021
67
没事你 rebase 干啥？建议你跟老大建议继续用 svn 吧，适合自己的才是最好的
|
 |
missdeerMay 25, 2021
68
get 到你的点了，但你的点前提是错的，在错的前提下讨论再多也没意义
|
 |
estMay 25, 2021
69
我觉得大家都让 LZ 去学或者看书，这种是无助于讨论的。
> svn 这种中心化模式，一个人 merger 好了，其他人 sync 一下即可。现在用了 git 每个人都要管理自己的 branch，自己去做 merge 同步，真觉得这样省力？ 其实 git 就是这样用的。每个人管理自己的 branch 可能是 LZ 走偏了。 |
 |
71
|
 |
h82258652May 25, 2021
72
别的不说，至少我觉得 svn 有两个地方是远远不如 git 的。
1 、分支，svn 的分支就是 copy 一份，每开一个分支，repo 体积多一倍。我们用 git 每发一个生产环境版本都要打一个 tag 的，svn 这样的分支设计难以支持； 2 、缺少 gitignore 对应的实现，这个在 svn 里要不就只能全局设置，不能对应到单独的 repo 上面，然而事实就是每个 repo 要 ignore 的确实不一样。最后结果就是 svn 的 repo 就提交了一堆没用的文件，包括代码编译生成的二进制文件，进一步导致了第一点问题的加剧。 |
|
73
@mxT52CRuqR6o5
perfoce/svn 大家会共用一个开发 branch，提交每一个 commit 前做冲突解决，开发前自己先拉下代码即可，从来没觉得代码同步、提交、合并会是个问题。而不像 GIT，等各人开发 一段时间，冲突已经积累一大堆。 |
 |
jones2000May 25, 2021
74
流程有问题吧. 每个人负责一个模块, 每个模块都是独立的文件, 一般不会多个人改同一个文件的.
|
 |
fiypigMay 25, 2021
75
只要分配各个模块，就不太会出现这个问题，除非是改到一些公共模块．．．
|
 |
fffangMay 25, 2021
78
@longway 不要直接 rebase branch，在自己的分支上用 rebase 将 commit 压缩成一个再 merge，这样 commit 只会是一个，也不需要一个一个进行 rebase 操作
|
 |
masterclockMay 25, 2021
79
@longway 使用 git，必须得 ”等各人开发 一段时间，冲突已经积累一大堆“ 之后再提交？
|
|
jones2000May 25, 2021
80
@longway 团队合作也不需要多个人开发 1 个模块吧， 如果是一般都是构架有问题， 继续拆模块， 把这个大模块拆成小模块，1 个人能做的那种，这样开发才能平行， 否则 1 个模块 N 个人做， 上一个人功能要等下一个人开发好， 才能继续开发， 还如果 1 个人做呢。 团队开发就为了提高效率， 比如 1 个项目你 1 个人需要做 1 个星期， 那老板直接说我给你 7 个人， 你 1 天时间给我开发完。
|
 |
neptunoMay 25, 2021
82
感觉是你们团队沟通问题吧，，，这个啥工具也救不了你
|
 |
ipwxMay 25, 2021
83
1. 你得用 branch 。branch 功能特别爽，每个人独立开发个把月，最后合并就行了。
2. 如果你们不能用 (1) 的方法工作，说明你们团队每个人的功能划分太奇怪了。哪有这么多的一起修改同一个文件的情况啊？这哪种工具都高效不起来啊喂。你们得有分组分层责任划分，每个组每个层和别的层除了接口其他互不相关才行啊。 |
 |
yyfearthMay 25, 2021
84
用过 svn/perfoce
当有 branch 的时候 而且差别很大的情况下 根本没办法 merge 只能一个个文件重新改 这样比 git 还难受呀 如果 svn/perfoce 只用 chunk 的话 就喝 git 只用 master 一样啊 都很简单的 |
|
ipwxMay 25, 2021
85
@masterclock @jones2000 所以就是楼主 @longway 团队的合作方式有问题啊。如果每天都有大量 conflict，说明根本没有进行团队工作切分，都是临时给人派任务。。。。这妥妥的缺少个架构师
|
 |
ccoMay 25, 2021
86
不知道是不是我不会用 git，我们提交代码的要求，第一不能积累太多内容，最好改一个 bug 合并一次。第二，合并完必须可运行。另外，大家都按照模块来开发，交叉开发不多见。
所以到目前为止，几乎很少会出现冲突，每天写代码前先 pull，然后再开始写，及时合并，及时 pull 。 |
 |
junnplusMay 25, 2021
87
看到楼上的回复我就放心了
|
|
ipwxMay 25, 2021
88
@longway 高效的大项目（也是 git 适合的场景）：每个组负责不同的子系统、组内每个人负责不同的子模块。每个人负责的文件都不一样，哪来的冲突机会？组和组之间的接口由总架构师协调，组内由组长协调。架构师干嘛的？不就是干这个的吗？
你一坨浆糊当然一直冲突…… 而且还没法开发更大的项目。 |
 |
ericguiMay 25, 2021
89
如果你们经常出现 conflict，那是你们领导出问题了，而不是 git 的问题
不管用什么工具，最后还是人来用，而众所周知，蠢人居多 |
 |
NielsenMay 25, 2021 via Android
90
开发流程的问题吧，就算是 SVN，你 merge 的时候一样也要改别人的代码（如果有冲突），只不过相当于大家都要等你 merge 完再 sync 。
换到 git，你也可以吼一声大家都别动，等你 merge 完都 pull 一下。 只不过牺牲了客户端的自由度，换取了对 commit 的绝对掌控。 |
 |
balabalagugujiMay 25, 2021
91
两个工具各有优缺点，个人比较喜欢 SVN，简单但是足够应付各种工作
|
 |
5200May 25, 2021
92
其实 GIT 在一些需要特定版本的项目中很方便。
觉得难用可能是没有使用到 git 的精髓，版本分支这块。或者一些场景 git 有更好的解决方案。 比如有一块大的功能，你开发完了，但是不急着上线，又有新功能模块需要开发上线，这时候使用 SVN 处理就会比较麻烦。 或者线上某个版本出问题了，要你马上回滚到特定的版本。此时一些新功能已经开发了一大块，且提交上去了。使用 SVN 也会比较麻烦。GIT 的话可以每个大版本都生成一个分支。 可以百度看一些 GIT 应用场景之类的文章，会有所收获。 http://www.ruanyifeng.com/blog/2015/08/git-use-process.html https://juejin.cn/post/6844903635533594632 |
 |
xFryeMay 25, 2021
93
工具是有适用范围的，我觉得你们内部团队管理出现的问题更大。。。
|
 |
christinMay 25, 2021 via iPhone
94
所以为什么不用 merge 要用 rebase ？
|
|
mxT52CRuqR6o5May 25, 2021
95
@longway 你说的这些 git 也可以做到啊，很多团队用 git 的方式就是在一个分支上开发，这是项目管理者自己选择的问题，而不是 git 的问题
|
 |
serge001May 25, 2021
96
你说的这些问题跟 git 有关系么?用 svn 几个人改一个文件也一样会有冲突
|
 |
clfMay 25, 2021
97
项目管理者的问题，而不是 git 的问题。
|
 |
DladMay 25, 2021
98
真有人觉得 8 车道大马路会提高生产力？
以前一直觉得大马路很好，不过最近需要到马路对面去。其他人也要去，人和车都非常多，等红灯的时间远超以前走乡间小路。 看这么多人吹村村通，不知道逻辑是什么，难道一个更加复杂的东西使用时会花费更少的精力？ |
 |
imkerberosMay 25, 2021
99
楼主太年轻, 没用过 CVS.
|
 |
securityCodingMay 25, 2021
100
没事用 rebase 干嘛...
|
1
Select Language