与普通 svn 客户端相比，使用 git-svn 有何优势？
我最近看到很多帖子建议，如果您必须使用 SVN 存储库进行团队开发，那么 git 是比 svn 更好的客户端：
这些文章似乎专注于如何使用，而忽略了原因。 帮助我说服自己、老板和同事，使用 git-svn 比官方 svn 客户端更有优势！
注意：git 和 svn 的相对优点已经得到很好的阐述。我更关心这个问题：在规定的 SVN 存储库上使用哪个客户端。
I've seen a number of posts recently suggesting that if you have to do team development with an SVN repository, git is a better client than svn:
These articles seem to focus on the how, and skimp on the why. Help me convince myself, boss, and peers that there's advantages to using git-svn over the official svn client!
Note: The relative merits of git and svn are well addressed. I'm more concerned in this question with which client to use on a stipulated SVN repository.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对我来说，使用 git-svn （和 CVS 桥）的主要优点是
作为奖励，git 与 SVN 和 CVS 的接口允许我选择退出争论，如果我们应该将我们的 CVS 存储库切换到 subversion（持续了 3 年多），或者立即追求一些非常酷和奇特的东西（持续了 2 年多） 。
您实际上不需要管理人员决定开发人员应该使用什么。无论如何，中央存储库所使用的内容可能是由其他参数驱动的（例如构建、审查和测试基础设施）。
For me the major advantages of using
git-svn(and the CVS bridge) are thatgit-blame,As a bonus, git's interfaces to SVN and CVS allowed me to opt-out the arguments if we should switch our CVS repository to subversion (ongoing since 3+ years) or go for something really cool and fancy immediately (ongoing since 2+ years).
You don't really need a management decision on what developers should use. What is used for your central repository might be driven by other arguments anyway (e.g. build, review and testing infrastructure).
对我来说，一切都与当地分支机构有关。当需要开始处理 BigNewFeature 时，我可以使用 git 创建一个新分支（本地）并开始处理它，按照我喜欢的方式提交每一步。然后，当有人不可避免地打断我在 BigNewFeature 上的工作并希望我修复 SmallTypo 时，我可以切换到 master 分支，修复拼写错误，然后将其推送到 svn。我可以返回 BigNewFeature 分支并继续处理我的业务。
这些廉价的本地分支为您作为开发人员提供了很大的灵活性，而当您必须处理 svn 分支和合并时，您就无法获得这些灵活性。我不害怕快速分支和实验。然后，当我对结果感到满意时，我可以将我喜欢的任何内容合并回 master 中，并以一组干净、易于识别的提交将其推送到 SVN。
For me it's all about the local branches. When it's time to start working on BigNewFeature, I can create a new branch (locally) using git and start working on it, committing each step of the way as I like. Then when someone inevitably interrupts me from working on BigNewFeature and wants me to fix SmallTypo, I can switch to the master branch, fix the typo, then push it to svn. I can go back to my BigNewFeature branch and go on about my business.
These cheap local branches give you a lot of flexibility as a developer that you just don't get when you have to deal with svn branching and merging. I'm not afraid to quickly branch and experiment. Then when I'm happy with the results I can merge whatever I like back into the master and push it to SVN in a set of clean, easy to discern commits.