为什么Git比Subversion更好？ [英] Why is Git better than Subversion?
问题描述
我几年来一直使用 Subversion ，并且在使用 SourceSafe ，我只是喜欢Subversion。结合 TortoiseSVN ，我真的无法想象它会如何更好。不过越来越多的开发者声称Subversion存在问题，我们应该转向分布式版本控制系统的新品种，比如 Git 。
Git如何改进Subversion？
比Subversion更好。但也不会更糟。这是不同的。
关键的区别在于它是分散的。想象一下，你是一名开发人员，在笔记本电脑上开发，并希望拥有源代码控制权，以便可以返回3小时。
使用Subversion，您可以拥有一个问题：SVN信息库可能位于你无法访问的位置（在你的公司，而你目前没有互联网），你不能提交。如果你想复制你的代码，你必须从字面上复制/粘贴它。使用Git，你没有这个问题。您的本地副本是一个存储库，您可以承诺它并获得源代码管理的所有好处。当您重新获得与主资源库的连接时，您可以对其进行提交。
首先看起来不错，但要记住这种方法增加了复杂性。 p>
Git似乎是新的，有光泽的，酷的东西。这绝对不是坏事（因为Linus为Linux内核开发写了一个理由），但是我觉得很多人跳过分布式源代码控制列车，只是因为它是新的，并且由Linus Torvalds编写，而没有实际知道为什么/如果它更好。
Subversion有问题，但Git，Mercurial，CVS，TFS或其他。
编辑：所以这个答案现在已经过去了一年，并且仍然会产生很多upvotes，所以我想我会添加更多的解释。在写这篇文章的最后一年，Git获得了很多动力和支持，尤其是在GitHub这样的网站真正起飞之后。我现在使用Git和Subversion，我想分享一些个人见解。
首先，分散工作时，Git首先会让人感到困惑。什么是遥控器？以及如何正确设置初始仓库？是一开始就提出的两个问题，尤其是与SVN简单的svnadmin create相比，Git的git init可以采用参数--bare和--shared，这似乎是正确设置集中的方式库。这是有原因的，但它增加了复杂性。 checkout命令的文档对于人们转换非常困惑 - 正确的方式似乎是git clone，而git checkout似乎改变了分支。当分散时，Git真的很闪耀。我在家里有一台服务器，路上有一台笔记本电脑，而SVN在这里根本不能很好地工作。使用SVN，如果我没有连接到存储库（我知道关于SVK或关于复制回购的方法），我不能拥有本地源代码控制。使用Git，无论如何这都是默认模式。这是一个额外的命令（git commit在本地提交，而git push origin master将主分支推送到名为origin的远程）。如上所述：Git增加了复杂。创建存储库，检出与克隆，提交与推送两种模式......你必须知道哪些命令在本地工作，哪些与服务器一起工作（我假设大多数人仍然喜欢中央主存储库 ）。
另外，至少在Windows上，工具仍然不足。是的，这里有一个Visual Studio AddIn，但我仍然使用带有msysgit的git bash。
$ b SVN的优点是学习起来更简单：存在您的存储库，全部如果你知道如何创建，提交和签出，并且你准备好了，并且可以在稍后进行分支，更新等操作。
如果一些开发人员并不总是连接到主存储库，那么Git的优势在于它更适合。而且，它比SVN快得多。据我所知，分支和合并的支持要好得多（这是可以预料的，因为这是它写的核心原因）。
这也解释了为什么它会在互联网上获得如此多的热门话题，因为Git完全适用于开源项目：只需分叉它，将更改提交到您自己的Fork，然后请原始项目维护人员进行修改。有了Git，这只是起作用。
我还看到的是Git-SVN Bridges：中央存储库是一个Subversion回购，但开发人员在本地使用Git和然后桥接器会将它们的变化推送到SVN。
但即使这么长时间的增加，我仍然坚持我的核心信息：Git不会更好或更糟，它只是不同。如果您需要离线源代码管理并且愿意花费额外的时间学习它，那太棒了。但是如果你有严格集中的源代码控制和/或努力引入源代码控制，因为你的同事不感兴趣，那么SVN的简单性和优秀的工具（至少在Windows上）就会闪耀光芒。
I've been using Subversion for a few years and after using SourceSafe, I just love Subversion. Combined with TortoiseSVN, I can't really imagine how it could be any better.
Yet there's a growing number of developers claiming that Subversion has problems and that we should be moving to the new breed of distributed version control systems, such as Git.
How does Git improve upon Subversion?
Git is not better than Subversion. But is also not worse. It's different.
The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.
With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.
With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.
This looks good at first, but just keep in mind the added complexity to this approach.
Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.
Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.
Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.
First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.
Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").
As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").
Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.
SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).
This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.
What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.
But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
这篇关于为什么Git比Subversion更好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
