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? ...
如果不上服务器，本地编译么， 分布式代码仓库在解决冲突这个问题上优势比较突出
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)
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