我_不知道故事的结局 - 歌单 - 网易云音乐
我_不知道故事的结局
我愿陪从你青涩时光到白发苍苍。
播放：380次
网易云音乐多端下载
同步歌单，随时畅听320k好音乐
网易公司版权所有(C)杭州乐读科技有限公司运营：
举报邮箱：违法和不良信息举报电话：3-20394Git诞生背后的一些故事 -- 简明现代魔法分支和合并Git 跟其他版本控制系统最大的优势就在于其高级的分支模型。Git 允许而且 鼓励 你在本地使用多个完全独立的分支。这些分支的创建，合并和删除几乎都可以在几秒内完成。这意味着你可以轻松的做如下操作：无痛的上下文切换 创建分支试验一个想法，提交几次，切回你原来分支的状态，应用一个改动 patch，切回你原来正在试验的状态，将刚才应用的 patch 合并过来。基于角色的代码支线 你可能会有一个分支仅仅包含那些只存在于生产环境上的代码，另外有一个独立的分支用以合并测试环境代码，还有若干个更小一些的分支用于日常开发工作基于特性的工作流 为每一个新的特性创建新的分支，你可以方便平滑的在这些分支之间无缝切换，当这些特性的改动完成的时候，你可以将其合并入主分支，并把特性分支删掉。任意试验 创建一个分支专门用来试验，当觉得试验不理想的时候，直接删除掉即可，放弃掉之前的试验内容。这时候不会有任何其他人察觉到这个试验（甚至在这期间你还可以推送其他不相关的分支）尤其是当你推送至远程仓库的时候，你不必推送所有分支，你可以选择只推送少数你愿意分享的分支，当然如果你愿意，也可以推送所有分支。这一点倾向于让开发者在试验很多新的想法的时候免除发布自己的未成熟的试验计划的顾虑。当然，也有一些其他的系统可以部分实现上述的功能和优势，只是具体的执行会变的困难和容易出错。Git 让这些工作变得难以置信的简单，它在开发者学习其使用的同时就改变了开发者的工作模式。轻量和快速Git 很快。Git 基本上所有的操作都在本地执行，这对于那些必须跟服务器通信的集中式系统是一个巨大的速度优势。Git 一开始是为了管理 Linux Kernel 的源代码设计的，这意味着他从第一天诞生就拥有了处理大型仓库的高效优势。Git 使用 C 语言编写，减轻了使用更高级别编程语言的 Runtime 带来的性能损耗。Git 最开始的两个重要的设计目标就是性能和速度。压力测试让我们看一下与 SVN （一个通用的集中式存储版本控制系统，跟 CVS 和 Perforce 很像）相比下的常规操作的性能测试指标。这里指标是值越小，速度越快。为了测试，我们在亚马逊的 AWS 的同样的可用区上新建了两个 Large 类型的计算服务器实例。每一个计算实例上都安装 Git 和 SVN。 我们把 Ruby 的源代码仓库拷贝到了 Git 和 SVN 的计算服务器示例上，两者都执行通用的操作。在有些情况下，两者的命令和实际效果并不能完全对应起来。在这里，我们在常用的操作中选择相似效果的匹配情况。例如，对于 “提交” 的测试，在 Git 中我们也是计算 Push 的时间的。然而在大多数情况下，你可能实际上并不会在提交后马上就推送到服务器上，这在 SVN 上是不可分割的操作。下面表格中所有的时间单位都是秒。你需要注意的是，这已经是 SVN 最好的运行场景了 -- 一个没有任何负载的服务器，客户端和服务器之间的网络带宽达到 80MB/s。上文中的所有指标在受网络波动，或者在一个更差的网络环境下 SVN 的表现都更差，然而 Git 这边几乎所有的指标都不受影响。很明显，在这些最常用的版本控制工具的操作中，甚至是在 SVN 的理想使用环境下，**Git 在很多方面都大幅领先 **。一个 Git 比 SVN 慢的地方是初始化 clone 仓库。在这种情况下，Git 是在下载整个仓库历史而不是仅仅是最新版本的代码。上文中的表格所示，仅仅执行一次的操作影响并不是很大。另外一个有趣的点是，Git 和 SVN 在 Clone 或者 Checkout 到本地后的文件大小几乎差别不大，要知道对于 Git 来说，本地可是包含了整个项目历史。这也展示了 Git 在文件压缩和存储上的超高效率。分布式Git 最棒的特性之一就是分布式。这意味着，你要 clone 整个仓库而不是仅仅 checkout 分支的最新头部版本。多个备份在日常的使用场景中 Git 往往有多个备份。这意味着就算在使用一个中央存储式的工作流，每一个用户都在本地有一个服务器上的完整备份。这里的任意一个版本都可以在服务器端数据损坏或者丢失的时候推送回服务器以挽救损失。事实上，只要你的仓库不是只有一个 copy，Git 就不会存在单点问题。任意工作流因为 Git 拥有分布式特性和极好的分支系统，你可以在此基础上轻松实现大量的工作流模型。Subversion（SVN） 风格工作流集中式存储的工作流非常常见，特别是对于那些从传统的集中式代码版本管理系统转过来使用 Git 的人。Git 一样可以提供这种工作形式：每次 Push 必须要更新到远程仓库的最新版本。所以说大家还是像以前一样使用集中式存储的工作流往同一个服务器上 Push 代码依然没问题。整合管理者工作流另外一个常见的 Git 工作流是整合工作流。主要的仓库有一个单一的开发者维护（维护者）。其他若干开发者从这个仓库 clone，然后推送到他们自己的完全独立的仓库里面，最后请求维护者从主要仓库 Pull 那些他们在各自的仓库里面的改动。这种形式往往在 GitHub 上以开源的形式进行协作。维护者和负责人工作流对于一些更为复杂的项目来讲，像 Linux 内核这样的开发工作流也是很有效的。在这个模型中，负责人（lieutenants）负责整个项目的一些特定的子系统，他们合并所有跟那个子系统关联的变动。另外一个维护者（dictator，字面理解：独裁者）只能从他管辖的负责人这里获取变更，并将这些变更推送到主要仓库。然后所有人都从这个仓库获取更新。数据校验Git 的数据模型确保了项目内的每一个字节，每一个 bit 的一致性。提交的每一个文件都会使用校验和计算摘要，检出的时候也使用这个摘要值。没有任何可能会出现从仓库中获取的内容跟你存储的内容有任何差异。在不改变 ID（校验和）的情况下也不可能出现改变任何文件，日期，提交说明或者任何其他在 Git 仓库中的数据。这就意味着，如果你有一个 commit ID，你不但可以确定这个版本的代码跟他提交的时候是一模一样的，而且这个版本之前的历史也没有发生任何改变。大多数中央存储的版本控制系统默认不提供这样的校验整合。暂存区域不像其他系统， Git 有一个概念叫做 “暂存区域” 或者 “index”。这是一个在提交执行之前的临时的区域可以用来格式化和审阅改动内容的。一个 Git 优于其他系统的功能是我们可以快速的暂存一些改动的文件，在工作目录中只提交部分改动的文件，或者文件改动的部分内容，以及在提交的时候在命令行里列出改动的文件列表。暂存区域允许你仅仅暂存部分的文件改动，在你意识到你忘了提交其中一个文件之前，对文件进行两个逻辑上不相关的修改的日子已经一去不复返了。现在你可以仅仅暂存你当前提交需要改动的文件，其他的改动在下次提交再暂存。这个特性可以扩展到对文件进行的任何更改。当然，Git 也允许你忽略掉暂存区域这个过程，你可以轻松的在 commit 命令后面添加 '-a' 选项来直接将所有改动提交。Git 会自动帮你先暂存到暂存区域，再执行提交。免费和开源Git 是一个使用 GNU GPL2.0 协议的开源软件。Git 选择 GPLv2 来确保你可以自由的分享和改造自由软件，而且能确保使用它的任何用户都是自由免费的。然而，我们确实也保留了 “Git” 和
避免争议。欲知详情请看我们的政策。注：本文转自 Coding 博客：译自 21添加评论分享收藏文章被以下专栏收录Coding.net 让开发更简单！看着日渐多的 Git，一个 SVN 粉的情怀
· 42 天前 · 8252 次点击
国内外现在遍地都是 Git 仓库，但是 SVN 做的好的没有一个，虽然很多 Git 仓库也支持 SVN 模式，但是功能是不齐全的。
我喜欢 SVN 的目录权限控制，还有它可以指定提交记录合并代码，当然还有它方便快捷的操作。
作为一个 SVN 死忠粉，这是不能忍的！！！
于是我自己做了一个
自认为是市面上最好的、功能最齐全的吧。
第 1 条附言 &·& 36 天前
还有个 SVN 用的特别爽的，就是可以单独 checkout 子目录，项目里策划、美术，测试，服务端，客户端，只需要 checkout 他们需要的目录就行了，爽的很，而 Git 需要整个仓库都 clone 下来，如果有很多美术等大文件的话，那是很痛苦的。
第 2 条附言 &·& 30 天前
关于 SVN 与 Git 的一些误解和真相，很好的文章
第 3 条附言 &·& 30 天前
看到很多人都对 SVN 有很大的误解，我特意翻译了一篇国外的文章，给大家了解到底是什么回事：
第 4 条附言 &·& 21 天前
域名最近变动，请大家改用 svn.gzyunke.cn 访问
149 回复 &| &直到
16:08:43 +08:00
& &41 天前 via iPhone
单干户，anyway，习惯就好
& &41 天前 via Android
同样喜欢 svn,权限管理不要太爽。工具也好用，除了不能分布式存储，感觉没什么问题，至于分布式的问题，本地建一个仓库，先提交到本地，再导出到远程，一样用的挺舒服。利用好分支功能协作开发一样挺舒服。估计说这么多怕是要被喷( o?? _ o?? )
& &41 天前
@ 我感觉分布式对我没啥用，分布式也就方便了你没网路时也可以提交，但是他大大增加了操作的复杂度，实在是不值。如果有人想说分布式可以保证代码更安全，不容易丢失，那 SVN 多个人 checkout 出去了，代码也一样不会丢失，每个人电脑上都有完整的代码。
& &41 天前
“大大增加了操作的复杂度”
你一定没用过 magit...
& &41 天前 via Android
猛一点，直接叫 svnhub 吧
& &41 天前 via Android
@ 其实是的，每次本地提交了都有 push 到远端备个份，怕本地电脑丢了。和用 SVN 没什么区别。。。
& &41 天前
@ 确实没用过 magit，提交本来就应该 commit 这么简单一句的事，还得用其他东西来解决，多麻烦
& &41 天前
@ svnhub 已经被人用了，我这个中文叫码桶，哈哈哈
& &41 天前 via Android
“大大增加了操作的复杂度”
不明白更复杂在什么地方，有对比吗？
& &41 天前 via Android
开发的人少，确实适合用 svn
& &41 天前
痛点不是应该在开分支吗。
SVN 签出代码以后，没办法少量提交，也没办法临时提交，结果就要么一个 commit 炒鸡大，要么没事就 commit 然后一不小心谁签入了奇怪的东西整个团队停下来等修复。
我司以前团队就是把 Git 当 SVN 用，全程只用两三个分支，一个团队挤在一个分支上互相干扰，然后还怨声载道，一个人签入了 broken 的代码，整个团队摸鱼半天……
& &41 天前
话说我一直用 sae 当 svn 用...
& &41 天前
觉得 svn 比 git 好用的，那你怕是没用过 pull request，跨 repository 协作，fork 一个出来改完就删。
更具体一点的，你怕是没改过别人的开源项目。
& &41 天前
顺便，GitHub 比别的 Git 平台最具有竞争力的地方在于它顺滑的 workflow。
给你的开源项目配置一个 Travis CI。别人 fork 一个到他自己的账号里面，随便改。和你的 mainstream 有分歧了也没关系，让他自己 pull from upstream，更新一下。然后他给你发个 pull request，Travis CI 会自动上线检查这个 PR。顺便你还可以做 code review。你们可以就这个 PR 进行讨论，他可以继续改代码，直到通过了 Travis CI 的测试和你的 code review，并且和 mainstream 不冲突（三个必要条件）。接着你按一下 merge 按钮，然后他的代码就合并到你的项目里面了。然后他就可以把 fork 出来的项目删掉了。
如果你能用 SVN 实现同样顺滑的工作流，我觉得 SVN 也不是不能用。所以楼主你自勉吧。
& &41 天前
来个 letsencrypt 就更好了
& &41 天前
@ 在开源项目方面，你说的这几点确实是 Git 好很多的，各有优点。SVN 的优点是小团队快速上手，操作方便，还有目录权限控制，这个对公司来说是特别重要的=
& &41 天前
@ 试试我这个吧
& &41 天前
@ 复杂在了你 commit 是提交到了本地仓库，你还需要 push 到远端别人才能看到，而且出现冲突，需要撤销代码等操作时都是 SVN 操作的两三倍的操作步骤，如果不是完全理解 Git 的工作流程，是很难在工作中用好的
& &41 天前
@ SVN 你也可以开个自己的分支，在分支上做自己的东西不会影响别人。
如果提交了错误的代码，自己可以本地撤销掉他的错误提交，不至于整个项目都卡住用不了，这个还是要看你有没用好 SVN，我参与过 50，60 人开发的团队，用 SVN 没遇到你说的这些问题。
& &41 天前
@ 多少其实都合适，一样的
& &41 天前 via Android
推荐域名 svnserver
或者 s.vn
svnhub 和 svnbucket 都太丑
& &41 天前
@ 空了我会做的
& &41 天前
@ SVNBucket 是模仿国外的 BitBucket 叫法
& &41 天前 via Android
@ 这个我知道，可惜 svn 不好配词，怎么搭配都是丑。。
& &41 天前
@ 我不知道你们一般会开多少个分支，不过我们是分支重度用户，每个人一般会有两三个分支，频繁 rebase 和 rewrite history，频繁尝试各种做法，经常 revert，频繁 fork&merge，频繁 CI 测试，用 SVN 甚至是 Mercurial 都达不到我们的要求。当然你也可以说我们没用好 SVN，不过既然 Git 能满足我们的要求了，也就没考虑去折腾 SVN 了。
另外关于#18，commit+push 我用 GUI 是可以一步做的，出现冲突的问题因为 Git 的分支特性所以出现得更少，可以频繁 rebase 也能够大幅减小分支间的差异，撤销代码直接一个 force push 即可解决，而且因为分支免费，所以可以随便 push 随便撤销，不会对他人有任何影响。
至于完全理解 Git 的工作流程，我觉得是工作所必须的技能，而且不仅要完全理解，还需要一个优秀的软件辅助，所以我们有御用的一款 GUI 软件协助我们完成这一切的操作。
& &41 天前 via iPhone
& &41 天前
@ Git 能完全掌握好的门槛高好多好多，特别是小团队，技术能力比不上大公司的，很多人用不好。用 SVN 和 Git 都没错，看情况，两者各有优点，根据情况使用。
& &41 天前
@ 你用的什么 GUI 软件
& &41 天前
@ 我们用的 SmartGit。
& &41 天前 via Android
@ 我一般用 idea 自带的 git，commit&push 是一步完成的，命令行下也可以设置 alias 吧。撤销代码有时用 checkout，有时 revert，有时 reset，有时还要 rewrite，根据需要精确控制，哪里复杂了？根据我的实践，平均工资 10K 多点的比较菜的团队，也可以用的很好啊。
& &41 天前 via Android
@ 用私有的 GitHub 不能设置权限吗？
& &41 天前 via Android
@ 不能按照目录设置，至少目前我没找到解决方案
& &41 天前
@ #32 弄成 sub module
& &41 天前
你只是用习惯了，懒的学新的而已
& &41 天前
公司用的是 svn，我只能说 svn 的 ignore 相比 git 有点复杂。
& &41 天前
真心觉得 svn 难用,同一个工程分目录的权限控制感觉必要性并不大..
& &41 天前
@ submodule 嵌套 submodule 很麻烦的…… 如果有人需要这种粒度的权限管理的话。
@ 不过话说回来，整个公司的代码树都在一个 svn 里面我觉得很不科学的，这是设计师的锅。好的设计我觉得应该可以分成独立的项目，有独立的测试，独立的 CI，独立的 Dependency 和 README，通过 API 互相松耦合。
& &41 天前
厉害厉害，逆天而行
& &41 天前
是啥关系？
为什么用了
的备案号。
难道
准备杀入 SVN 市场？
Ps：头像上传失败，签名自动出现「 undefinded 」
& &41 天前 via Android
& &41 天前
svn 的 merge 很弱啊…多人开发想死
& &41 天前
@ 命令操作上确实 SVN 的 ignore 会比 Git 的麻烦，不过 GUI 操作就简单很多了
& &41 天前
这么厉害。
& &41 天前
@ 说实话不太敢，因为 svn 挂了就都没了.... git 没事，可以同步多个 remote，这个估计就是 svn 提供商少的原因吧。不是大厂不敢用...
& &41 天前
@ 因为你不是一个公司的代码管理者，客户端、服务端、策划、美术等各种人员同个项目不同权限是很重要的
& &41 天前 via Android
目录权限可以用 git 的 sub module
& &41 天前
@ 你可以问下那些人，看下是否完全掌握
& &41 天前
@ 不是整个公司的代码都在一个项目里，当然是要不同项目不同 SVN，但是一个项目会有多种角色：客户端、服务端、策划、美术等，需要为他们设置不同目录的权限
& &41 天前
@ SVN 的 merge 非常好用呀，可以指定具体的某条提交记录合并到另外的分支，Git 好像是没法做到？你可以看下我写的 SVN 快速上手教程，里面有个说 merge 的：
& &41 天前
@ SVN 可以做备份的，挂了可以恢复备份，都是多份容灾的啦，没有你说的挂了就没了的事
& &41 天前 via Android
@ svn 合并很弱的，多分支合并的时候你就知道有多蛋疼了
& &41 天前
我们再来个 mercurial hub 以及 fossil hub 吧。嗯，git 还有一个缺点，至今不支持断点续传。
虽然我只会不用没设置 alias 的 git 命令行
我习惯全手打命令。
svn 支持 commit 的 gpg 签名么？
不太懂如何混合多种编码（比如我要测试三种编码的读入）原文件 commit 到 svn，要能正常 diff。
svn up 网络中断，似乎可以接着来呢
& &41 天前 via Android
@ 我自己都没有完全掌握，他们当然懂的更少，可是这并不妨碍我们用的 666。能懂个 20%左右就可以正常使用了。
& &41 天前
SVN Git，是不同场景不同需求下的不同版本控制系统。没有哪个是绝对完美的，要根据具体情况进行选择。
另一方面使用的方法也是很重要的，使用 Git 的话要根据具体的项目流程和团队协作方式设计具体的 Git 流程，工具是死的，人是活的，没有什么问题是完善流程和约定原则解决不了的。
& &41 天前
先不管 svn 好不好，建议楼主开源吧。要不然等有人用起来，把你塞几个服务器都不够的
& &41 天前
@ 你肯定没掌握好合并的方法
& &41 天前
@ 只懂 20%肯定用不好，Git 的代码撤销就分很多情况的操作
& &41 天前
@ 如果只是某条的话,cherry-pick 就可以了
git 定位问题 的二分查找简直不要太爽,随意 checkout.
& &41 天前
@ #45 这些肯定都是分开的啊..为啥会在一个工程里..
& &41 天前 via Android
你也可以把 git 用成 SVN 啊
& &41 天前
我也觉得自己私有的项目用 svn 简单多了
之前一直在用
，也马上要关闭了
& &41 天前
@ 对的，各有优缺点，需要根据情况选择使用。我对 SVN 比较有感觉，市面没有一个好用的，所以自己做了一个，希望大家多支持啦
& &41 天前
@ #59 有时候喜欢把同个项目的东西放同个 SVN 仓库，客户端、服务端、策划、美术，全部在一个仓库，这样便于管理和使用，当然你分开一个个单独的仓库也是没问题的，个人喜好吧
& &41 天前
@ #61 那支持下我这个吧
& &41 天前
@ 我怀疑他们懂的连 10%都不到，之前都是用 svn，简单培训了个把小时就转 git 了。代码撤销的姿势很多，但是可以无视这些姿势，只用 checkout 也能达到相同的效果，区别就只有历史好不好看。大家用脚投票投了 git，真要那么复杂，应该 svn 比 git 流行，而不是只剩下情怀。
& &41 天前
#49 @ 相信我，分支管理上 Git 甩 SVN 无数条街。
我们先把 SVN 开分支会把整棵树复制一遍的问题放一边。
你说的 Merge 在 Git 上也是很简单的，对我来说就是右键签出新分支，然后右键合并，就把 base 到当前指针的内容 Merge 到主分支上了。根据具体情况需要，我们还会选择 Rebase，也就是把分支的根直接搬到主分支上。如果 Merge 完以后原来的分支还需要继续开发，那就把新的分支 Rebase 到 Merge Commit 上就行了。
你前面说 SVN 的撤销，如果指的是上面教程里说的 Revert 的话，那个是撤销更改而不是撤销提交。比如说你不小心把自己的银行卡号密码提交进 SVN 了，你怎么办，Revert 吗？这样并不会删掉你的私密信息。但是 Git 允许你直接从历史中剔出不需要的部分。比如说我司以前会把几个二进制文件提到源代码目录里，结果每次更新以后仓库就会变大，最后整个仓库达到 2G 上限，撑爆了 Bitbucket 上的空间。后来我们直接重写项目历史，把这几个文件的所有提交从仓库里踢出去，删完以后仓库还是那个仓库，提交还是那么多提交，只是容量大幅减小了，那几个二进制也从历史中彻底被抹去了。换成 SVN 怕是要重新建库了吧。
Git 的好处是可以用任意的方式对文件的更改进行任意地组合、变更、揉捏。所以我司的变更记录从上到下是很干净的，特性全部采用分支+合并，小提交全部根据开发阶段进行归纳，能保证出问题的时候可以 bisect 可以单 commit revert。这也意味着我们的库上不会有多分支同时合并的情况，也不会有合并冲突的情况（必须先 Rebase 解决冲突，然后再 Merge ），也避免了隐藏在 Merge commit 中的隐形更改影响系统运行的情况（在我们的代码里发生过的，Bug 出现在合并节点的 Conflict resolver 上）。
我能够理解很多公司使用 SVN 的场景（权限控制，不懂 Git，等等），但是从功能上来说 SVN 太不堪用了。
正好说说夹在两者之间的 Mercurial。Hg 和 Git 是同一时期开发出来的，Hg 很明显是借鉴了 SVN 的思想，版本都用版本号，开分支会影响提交记录结构（意味着你开分支，那你下一个提交的版本号就变了），所以你拿 Hg 和 SVN 比的话倒还是可以比一下的。
不过 Git 是彻底删除了版本号的概念，没有了版本号以后，开分支就不像 Hg 那样会产生副作用了，提交和提交之间也不需要再用版本号相连接。
（ Hg = SVN + 分布式； Git = Hg - 版本号）
坏处是……学习曲线真的是太(TM)高了，我感觉我从入门到能熟练掌握 Git 的顺滑流程，大概花了有六七年。
但是转念一想，大家都是软件工程师，骨子里应该会有那种对优雅技术的向往吧，不会想着去想办法掌握它吗……
& &41 天前
楼主提了三个点
& 喜欢 SVN 的目录权限控制
git 是拆分多个代码库，使用 submodule
& 还有它可以指定提交记录合并代码
git cherry-pick
& 当然还有它方便快捷的操作
说简单是可以的，但是你说方便快捷就是。。
SVN 冲突解决真的很想屎，拉分支同样想屎
Git 最大的缺点是秉承了 Linux 哲学，不限制你做任何事情，造成 workflow 多种多样，然后一帮只会瞎 commit 的人各种污染历史。但是这个好办，开启 Code Review 后直接怼几次就乖了
& &41 天前
有些人 35 岁就要被辞退是有原因的, 用惯了自己那一套后就抵触新技术.
然而到最后他们也没闹明白新技术为什么就把旧技术给淘汰了
& &41 天前
@ 你说的没错，Git 是很灵活，时代的趋势，不过相信还是有很多跟我一样喜欢 SVN 的朋友，希望给同样喜欢 SVN 的朋友一个平台吧。Git 完全掌握全部东西真的需要很久，很有经验的人。
& &41 天前
@ SVN 的冲突解决一样很简单呀，可能是你没掌握好方法
& &41 天前
@ 朋友，我不抵触 Git，只是挑选一个自己喜欢的用而已，大家各有所好，Git 和 SVN 各有优缺点
& &41 天前 via iPhone
@ 那是你没有开发过大项目
& &41 天前 via iPhone
@ svnhub.io 呢
& &41 天前
不纠结于用什么工具，只专注能做出什么产品。
& &41 天前
至少这种作产品的情怀要赞一个
& &41 天前
@ 感谢支持，希望给一些依旧喜欢 SVN 的朋友一个好的平台。
& &41 天前
@ #72 我参与过网易 50~60 人的游戏开发，也是用 SVN，我了解到整个网易都在用 SVN 做代码管理。我去过的所有公司都是用 SVN 的，不过现在逐渐多的公司开始使用 Git 了。
& &41 天前
@ #73 暂时不考虑换名字了，SVNBucket 这个名字我自己还比较喜欢
& &41 天前 via iPad
@ 十年前或者说五年前大家都用 SVN
现在都用 GIT，SVN 好用的话为什么要换
& &41 天前
@ 你的观点有道理，既然你司用了 SVN，就可以用目录权限而不是恰当地划分项目的方式管理项目。其实也道理很简单，用了一个工具（或者语言），你的 workflow 和 design pattern 就受到工具的影响。违逆工具（语言）的 workflow 和 design pattern，怎么都会别扭的。
当然，你说 git 多支合并或者其他合并很困难，这点我不同意。Git 完全没有版本号，所以理论上你可以做任何操作，不要说多支合并，跨 repository 合并都没什么难度。这个还是学习曲线的问题。
不过我还是要评论一句。我觉得 git 的 best practice （符合 git 的 workflow，就是合理划分项目，用 submodule，pull request 等）比 svn 的 best practice （符合 svn 的 workflow，比如你说的目录权限）总体上更好用。
& &41 天前
@ #80 其实就是 Git 操作比较复杂了，得记住很多命令、概念，不然用不好。当然要是完全掌握好了 Git，就会感觉如鱼得水，爽的很，就好像一个人熟练掌握了 Vim 的使用样。用什么工具都没问题，只要掌握好了方法，都能用的非常好。
& &41 天前
过来人说一下
相信我用 svn 的历史要比你长, 部分出于惰性我也有过很长时间让项目继续在 svn 中衍生
还有一个重要原因就是 git-svn 的不完美, 如果你希望能保留代码的完整历史以及分支结构, 而 svn 的代码已经有了很复杂的历史的话, 基本上光依靠工具是没有可能做到的
当终于立定决心要扔掉这个历史包袱，我花了差不多三个月时间才把代码按预定规划完全转换过来，再花差不多半年时间把流程理顺，之后我相信不会有任何人继续希望在任何开发项目中使用 svn 的。
都这个年代了，如果还拿学习成本高说事我就觉得有点不负责任了，人员素质肯定会参差不齐，这根本就不是一个理由，关键还是看管理者的水平
& &41 天前
@ 嗯，你的做法没错，而且很好，学习新的东西永远都是应该鼓励的。不过当前还是会有很多 SVN 使用者的，作为小公司和小团队来说 SVN 可能会更加省事、靠谱，过几年再转 Git 也不迟，也不会说没用 Git 就工作上损失了。
& &41 天前 via iPhone
简单点说就是 git 是面向开发人员，svn 适用于整个团队，精细权限控制用 git 是没法代替的
& &41 天前
@ 说个鬼故事，submodule 我觉得炒鸡难用……
& &41 天前
& &41 天前
一个公司团队里，有多少人能真正完全掌握 Git 的各种操作，我估计 2/10 样子吧，其他都是只会 push、pull 等一些必用的操作
& &41 天前
@ 我曾见过 low 到爆的团队，他们用文件改名控制版本，理由还一箩筐
& &41 天前
@ 不知道你见过一个大版本就把整个项目文件夹复制一份然后后缀版本号加一，然后整个全部上传到 svn 的所谓‘版本控制’不。。有一天发现公司 svn 服务器空间莫名减少不少，找了半天发现了这个神奇的仓库，svn 的提交次数等于仓库里项目文件夹的个数……骚操作来自一个平时牛逼轰轰的独立 ios 开发，我纠结了好久要不要找个方式告诉他版本控制不是这么一回事——而当我发现仓库里每个项目文件夹下其实都还有个.git 目录的时候我决定放弃，任由这哥们自生自灭吧。。。
& &41 天前
其他不说，就楼主能把 svn 线上平台折腾出来的这个执行力我觉得就非常值得赞赏。
& &41 天前 via Android
git 最佳实践门槛高，学会再也回不去。
& &40 天前
@ #89 其实不懂使用 SVN 和 Git 的人大把。前不久我问一个朋友，你怎么转 Git 了，他说 Git 好多了呀，可以切分支；还有说 SVN 不能同时修改同个文件的，会冲突。这完全就是还没掌握嘛
& &40 天前
@ #90 多谢鼓励
& &40 天前
@ #88 这种还不是少数，很多小团队和小公司，招不到好的人才，都会出现这种情况，用不好、不会用。
& &40 天前
@ #91 这跟 Vim 是一样的，门槛高，掌控好了就会感觉很爽
& &40 天前 via Android
@ 比 vim 门槛低得多
& &40 天前 via Android
我挺喜欢 svn 的文件图标
& &40 天前
楼主的项目设计的很规整，不知是个人还是公司作品。
& &40 天前
@ 我也不知道怎么说，我是独立创业者
& &40 天前 via Android
在我看来，svn 的功能是 git 的真子集
& · & 751 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 87ms · UTC 18:44 · PVG 02:44 · LAX 11:44 · JFK 14:44? Do have faith in what you're doing.