git的分布式有点疑问
集中式（SVN）和分布式（Git）版本控制系统的简单比较 - Raychan - 博客园 (cnblogs.com)看了上面文章，结合目前所在项目开发现状，有些疑问
没有中央服务器，开发人员本地都有 Local Repository
～～～～～～～实际项目中，第一次项目成员还是需要git clone git@x.x.x.x:branch local_dir_name，不可能自己构建仓库
分布式在没有网络的情况下也可以执行commit、查看版本提交记录、以及分支操作，在有网络的情况下执行 push 到 Remote Repository。
~~~~仅仅是缓存而已，最终还是要联网，产品构建需要所有成员提交各自代码共同编译；稳定的办公场所一般不会出现断网，
总之，没看出分布式啥优点，
Git 可以每个人都有自己的版本库.
SVN 则是只能有服务器一个版本库. 为什么不能自己构建仓库, 最简单的你github上fork了不就构建了一个自己的repo? roamer 发表于 2022-4-13 17:32
为什么不能自己构建仓库, 最简单的你github上fork了不就构建了一个自己的repo? ...
如果不上服务器，本地编译么， 你如果能 ssh 登别人的账号，那可以直接 clone push 对方的本地 repo 分布式代码仓库在解决冲突这个问题上优势比较突出
svn 的开发习惯往往是不开分支. commit 时如果出现冲突, 就必须先 update, 在本地解决冲突, 然后再 commit
假如仓库 commit 比较频繁, 这时可能又引入了新的冲突, 导致长期无法 commit, 反复在 update 时解决冲突也很累人
而且成功 commit 之前, 旧有的未提交的修改一直有丢失的风险
git 把解决冲突的工作集中在了 push / merge 前的 pull 阶段
平时 commit 肯定不冲突
本地轻松建立分支 & 支持细粒度提交也能促进更好的开发习惯
再就是现在流行的代码托管服务 / 工具基本都支持 git
文章里说 git 资料少, 不符合常规思维, 这应该都是老黄历了
git "没有版本号"应该是指没有内置的整数 commit ID, 这可以用构建系统的 build ID 来替代, 或者自行发明整数版本号
git "代码保密性差" svn 仓库也可以被整个复制到本地, 只要有读权限: https://git-scm.com/docs/git-svn
svn "代码一致性非常高"这个也不知道是在说啥: commit 后但暂未 update 的状态, 此时整个代码树是新旧版本混杂的. 无法用一个 commit ID 来指明, 比 git 更缺少一致性.
现在 svn 基本只考虑给无法轻松迁移的旧项目用 上面说的都差不多了
其实我觉得git的最大优势就是可以本地建立分支的代价小
不像svn那样分支很重，冲突多的时候合并一次代码简直要死 现在流行肯定是git啊，svn的分支谁用谁知道，git的分支可以说是基本没成本了
分布式是为了让大家都各自在自己的分支上干活，拉下来之后没网也可以继续写，最后提交进主分支之前来个merge/rebase就行了
svn那不行，时时刻刻都要连着服务器，没服务器什么都干不了，想一想，就更不适合现在WFH的趋势了
git最大的缺点……在于命令和参数算是拍脑门想的，乱七八糟的
git对非文本的二进制文件支持不太好，当然svn也不怎么样。 5long 发表于 2022-4-13 19:20
分布式代码仓库在解决冲突这个问题上优势比较突出
svn 的开发习惯往往是不开分支. commit 时如果出现冲突,...
svn也有branche tag这两个机制开分支；
对于冲突，我看了下
https://blog.csdn.net/ericwang_1992/article/details/118972904
好像和svn也差不多，就是提交前先update，svn也会生成冲突文件，好像叫xxx.mine文件
顺便，冲突这点和分布式好像没啥关系， b0207191 发表于 2022-4-13 20:59
svn也有branche tag这两个机制开分支；
对于冲突，我看了下
CSDN 这个文章里的冲突解决办法等于是把 svn 的操作习惯照搬到了 git 上
文中的示例只有一次提交
虽然不是不能用, 但不是唯一的办法
git 的习惯做法是平时就可以积极地细粒度 commit
维护一个易于 review / revert 的代码演进历史
在 pull 上游的时候再集中精力解决冲突
svn 的 branch 是能用, 假如团队成员的确也能习惯 & 愿意坚持用, 也可以. Jet.Black 发表于 2022-4-13 20:12
git对非文本的二进制文件支持不太好，当然svn也不怎么样。
现在有 git lfs 这个插件了
大文件可以只 fetch & checkout 最近一个版本
不需要访问大文件的用户可以只留一个指针文件, 节省空间和时间
用着还凑合. https://www.bilibili.com/video/BV1xb411A7ac
linus 本人在谷歌的讲座，理由给的很多了。
唯一服务器导致的分支命名空间问题
唯一服务器带来的命令操作网络开销问题
唯一服务器导致的单点故障问题
svn本身对分支合并弱到约等于没有的支持导致合并极其痛苦的问题
说实话，这些东西都是规模起来之后才有意义的。 几个人的，只有万行代码级别的，没几个分支的玩意，用git还是svn差异不会有那么大的。 本帖最后由 b0207191 于 2022-4-13 23:02 编辑
http://app.myzaker.com/news/arti ... 46bdc86&f=weixin_mp
又看了一篇介绍
Git 并不比 Subversion 更好，它只是不同
首先，让我们来看看 Git 是否（比其他流行的版本管理工具）更好，甚至最好。以 Git 市占率成为第 1 前最流行的 Subversion（简称 SVN）来对比。
在美版知乎网站 StackOverflow 上曾经有一个问题《Why is Git better than Subversion?》，被采纳的高赞回答是这样说的：
Git is not better than Subversion. But is also not worse. It's different.
是的，只是 different。有哪些不同呢？从 Git 官网的介绍和 Subversion 官网的介绍可以看出来：
# Git Subversion
#1 distributed centralized
#2 branching and merging simplicity of its model and usage
#3 small and fast wide variety, from individuals to large-scale
#4 data assurance reliability
#5 open source open source
上表是 Git 和 Subversion 官网强调的几个特性，我们来分析一下：
1. 分布式和中心化，Git 和 Subversion 完全不同的思路；对于开源社区（比如 Linux），显然分布式更合理，但对于商业公司，恐怕中心化更方便运维和备份；2.Git 更强调低成本的分支（和合并），Subversong 也支持分支和合并，但更强调简易的模型和易用性；3.Git 强调的是轻量和快（性能），而 Subversion 强调多用途（不仅仅是代码，还支持二进制文件）和规模；4. 说法不同本质一致，强调数据的可靠性；代码是 IT 公司的核心资产，可靠性怎么强调都不为过；5. 都是开源和免费的软件；
(39条消息) 怎么区分 项目时 svn 还是 git_开眼了，腾讯是如何使用 Git ？_weixin_39819152的博客-CSDN博客
(29 封私信 / 1 条消息) 百度、阿里、腾讯之类的大公司用 Git 吗？他们如何管理源代码？ - 知乎 (zhihu.com)
svn适合管理assets，因为不会有很多版本分支 git你只需要一个客户端就可以开始版本控制了，只在需要的时候偶尔和服务器或者别人，甚至自己电脑的另一个目录同步，原理简单但是足够灵活以于是有很多玩法，至于homebrew之类的包管理直接也用它当数据库使。 你看一眼linux的补丁流程就可以看出分布式了
举例说一个无线网卡的驱动补丁
最开始在开发者本地仓库开发->pr到对应的驱动仓库，比如mt76->pr到wireless-next仓库->pr到net-next仓库->pr到linux-next仓库->pr到mainline仓库
中间的仓库都算是分布式的，和mainline独立 对于git本身来说，它并没有客户端和服务器的概念.........你的repo和服务器上的repo所包含的信息实质是没区别的 草了，你先都用一遍再说。svn开分支你先体验一下，什么垃圾
—— 来自 HUAWEI NOP-AN00, Android 10上的 S1Next-鹅版 v2.5.2-play calmer 发表于 2022-4-14 07:36
草了，你先都用一遍再说。svn开分支你先体验一下，什么垃圾
—— 来自 HUAWEI NOP-AN00, Android 1 ...
SVN开分支要把文件夹都复制一遍，太弱智了 ....lz不要纸上谈兵，两者都用用就能体会了呀（github上随便fork几个项目玩玩）
大厂现在代码管理的方式，据我所知应该基本都切换到git上了（除了有些老项目无法迁移的）
就是因为很多需要多人协作的超大型项目，svn用起来非常痛苦，特别是多个feature并行开发和发布的场景（可能还包含很多fix也在并行）
这种情况git可以很容易用多分支来解决
你感到困惑应该是没有在实际工作中接触到这种大型项目，迭代慢的小项目说实话git比svn并没有太多的优势 其实习惯svn的话用不惯git的话，掏钱买perforce不香么....
就算不用，免费的 p4merge也吊打其他gui merge工具啊 都2022年了怎么还有这样的问题，就算你不爱看文章，自己搭两台服务器试试不就知道了吗，如果觉得都是垃圾麻烦您造个轮子，喜欢的人都会付费。 kztp 发表于 2022-4-13 21:29
https://www.bilibili.com/video/BV1xb411A7ac
linus 本人在谷歌的讲座，理由给的很多了。
唯一服务器导致 ...
从分支git merge到主干出现conflict也是要靠人工判断冲突位置在根据业务逻辑修复来解决，那么和手动从分支复制到主干有啥区别 b0207191 发表于 2022-5-8 21:22
从分支git merge到主干出现conflict也是要靠人工判断冲突位置在根据业务逻辑修复来解决，那么和手动从分 ...
没什么区别，最核心的业务逻辑代码差异还是只能人工处理。
差异在于git在工作模型上就为分支合并预留了对应的概念和工具，可以协助处理冲突甚至自动处理部分小冲突。可以让开发人员将精力集中在”业务逻辑代码流程差异“这种级别的差异必须人工才能处理的差异。
比如有合并信息作为整个log数的一部分之后，git能支持rerere这种简化后续的二次、三次合并时的工作量的功能。
所以说规模起来之前git和svn差不了多少。就那么点提交量、合并次数，根本遇到不git搞起来很轻松，svn搞起来搞死人的场景，反而只会让用的人觉得”为什么git要另外引入那么多概念，又没用又难懂，脱裤子放屁” 第一层楼里的两个结论全都是错的尽然没有人指出？…本地直接git init就行，另外本地也是完整的仓库，pull和push只是在两个库同步，本地两个目录之间也可以互相pull push，非常自由的… 比如某个没有版本管理意识的外包发来一个压缩包（不一定是源码，程序包什么也都可以），过一会有人提bug改改又发一个来，如此反复，就经常直接顺手解压完git init，每次新文件来了，增量包就覆盖然后git commit，全量包就删掉只留下.git文件夹，重新解压再git commit，哪里不对了回退或者比较版本都很方便，完全不需要服务器参与，本身就是完整的版本控制 上面这类场景才是分布式和集中式的差异，至于合并冲突啥的，版本控制只是方便看双方修改的点，然后根据逻辑来，这一点上分布和集中的优势只是体现在没必要过早合并，减少合并的次数，不到真的最终版本之前，分布式的都没必要过早合并，减少不必要的反复合并 所以git要怎么来做权限控制？分仓库再集成吗 thegodra 发表于 2022-5-9 12:22
所以git要怎么来做权限控制？分仓库再集成吗
其实submodule就可以吧，还有hook也能 想要权限控制的新系统用SVN，然后客户端用 git 连服务器的 svn。可以认为是集中了两者的优点。
https://www.cnblogs.com/h2zZhou/p/6136948.html 更新下关于git中rebase merge的疑问，
对于不同分支，无论是master还是branch上做的修订，让工具来做，基于文件才可靠吧，如果是同一个文件，不同函数就危险了（非代码文件，就没有函数的概念），因为工具无法理解文件中体现的业务逻辑
类似的，各种diff工具也有这种问题，只能使用固定算法比较，所以显示的区别未必是最优的
git 的分布式的含义是每个节点都存储了仓库的完整镜像
Linux Windows Android Chrome 的源码都在用git管理，git一把梭就对了，有啥好比较的？
— from Google Pixel 6 Pro, Android 13 of S1 Next Goose v2.5.4 1.svn没了服务器就摸了
换git的话，你，就是你自己的服务器
2.只能去公共厕所解手，和可以去朋友家/朋友来自己家解手的区别还是很大的
以git的流行状况来看，一个开发者很可能不用学svn，却很难不学git
—— 来自 S1Fun 有个疑问，如果代码回退到一个版本，然后提交新的修改。对于svn每个提交都有merge,就1条提交线，别人更新拉下来也不会有冲突。但是git虽然自己啥也没改，但和本地是2条线了，一拉下来代码就和本地冲突了，这个git的通常做法是啥？ 前两天发现git可以写hook
算是彻底的解决了不小心commit一个100m大文件的问题...
页:
[1]
2