blocks|key|746876|text|不是的。至少对我来说不是。对单个开发进行非集中式回购有什么意义？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|746877|而且，Git工具并不完全适合TortoiseSVN栏。|746878|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

No. At least not for me. What's the point of having a non-centralized repo for a single dev?

Also, the Git Windows tools aren't quite up to the TortoiseSVN bar.

blocks|key|2271194|text|关于Git，有一点可能很吸引人，那就是您可以继续工作，并且可以脱机提交。所以，当你在飞机上的时候，带上你的笔记本电脑，像往常一样提交。当你回到网上，你可以推回你的主要回购。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2271195|如果您发现您做了很多分支，您可能会更喜欢Git，因为它的设计是为了使分支/合并变得简单和常见。|2271196|更新：注释--您可以在不提交Git的情况下测试它，因为Git可以与SVN+repos对话。。所以，试一试，如果你不喜欢它，什么都不会失去！|offset|length|style|BOLD|2271197|entityMap|0|LINK|mutability|MUTABLE|url|http://utsl.gen.nz/talks/git-svn/intro.html^0|0|0|0|3|R|I|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@$F|U|G|V|H|I]]|9|@$F|W|G|X|1|Y]]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

One thing that may be compelling about Git is that you can continue to work and do commits offline. So, when you are on the plane, bring your laptop and commit as usual. When you are back online, you can push back to your main repo.

If you find you do a lot of branching you will probably prefer Git, as it is designed around making branching/merging easy and commonplace.

Update: Note you can test out Git without committing to it, since <a href="http://utsl.gen.nz/talks/git-svn/intro.html" rel="nofollow noreferrer">Git can talk to SVN repos</a>. So give it a try, and if you don't like it, nothing lost!

blocks|key|746971|text|这取决于你的工作流程。你经常在无法到达svn服务器的地方工作吗？您的项目是否有大量的分支，因为您喜欢同时处理多个(大的)事情？你复制机器之间的工作副本吗？您是否将新的分支从现有的分支中分离出来？你有时会在后备箱上工作，中途会觉得“我应该在树枝上做这件事”吗？如果是这样的话，那么它可能是有用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|746972|从单个开发人员的角度来看，像svn这样的中央系统与git这样的中心系统之间的主要区别是，在svn中，修订是线性的。这是一棵树。当您处理要在多次提交中执行的更大功能时，这是非常有用的。|746973|示例:您有一个很大的特性F，它由更改a、b、c和d组成。使用Subversion，您可以在主干上分别提交a、b、c和d，或者创建一个分支，这意味着您必须进行大量合并。使用git，您可以签出一个工作副本，在其上提交a、b、c和d。然后你把它作为一个单一的变化F推给你的主人。因此，在主干上只看到一个提交，而不是四个提交。这使得从日志中更容易地看到正在发生的事情。|746974|您也可以使用svn分支来完成这一任务。但是现在假设a部分也由多个部分组成，比如a1和a2。|746975|这样的开发模型可以用Subversion来完成。例如，就是这样做的。所有的开发都是在树枝上完成的，没有人在树干上工作。但是git使得这样的工作流变得更容易。|746976|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

It really depends on your workflow. Do you work often from places where you cannot reach your svn server? Do your projects have a large number of branches because you like working on several (big) things at the same time? Do you copy working copies between machines? Do you split off new branches from an existing branch? Do you sometimes work on the trunk and halfway through a bunch of changes think "I should have done this in a branch"? If so, then it may be useful.

From a single developer's point of view, the main difference between a central system like svn and a decentral system like git is that in svn the revisions are linear. With git it's a tree. This is useful when you work on bigger features that you want to do in multiple commits.

Example: You have a big feature F that consists of changes a, b, c and d. With Subversion you'd either commit a, b, c and d separately on the trunk, or you'd create a branch which means you have to do a lot of merging. With git you check out a working copy, commit a, b, c, and d on it. Then you'd push that as a single change F to your master. So, instead of four commits you see just one commit on the trunk. This makes it easier to see from the log what is going on.

You could do this with svn branches as well. But now suppose that part a also consists of multiple parts, like a1 and a2.

Such a development model can be done with Subversion. Python Twisted is done that way for example. All development is done on branches and nobody works on the trunk. But git makes such a workflow easier.

blocks|key|905174|text|我可以给你三个好处：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|905175|您可以拥有多个备份存储库。Git不是集中式的，所以您可以在您正在工作的任何机器上保持您的回购，并将更改推送到任何备份位置。我把我的记录保存在github和其他两个地点。|ordered-list-item|offset|length|905176|分支，合并，重基，修改提交，git均分。仅仅因为您是一个开发人员，就没有理由不使用最好的工具。|905177|git-svn+-你可以在你做决定的同时，在你的颠覆版本恢复的同时尝试它。|905178|这有一个缺点，那就是Windows上可用的可视化工具并不像其他平台上的工具那样友好。|905179|entityMap|0|LINK|mutability|MUTABLE|url|http://github.com/^0|0|1Y|6|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@$E|W|F|X|1|Y]]|A|$]]|$1|G|3|H|5|D|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

I can give you three advantages:

<ol>
<li>You can have multiple back up repositories. Git isn't centralised, so you can keep your repo on whatever machine you're working on and push changes to any back up locations you have. I keep my repos on <a href="http://github.com" rel="noreferrer">github</a>, and two other locations.</li>
<li>Branching, merging, rebasing, amending commits, git bisect. Just because you are a single dev, there is no reason not to use the best tools.</li>
<li>git-svn - you can give it a try in parallel with your subversion repos while you make your mind up.</li>
</ol>

There is a disadvantage; and that is that the visualisation tools available on Windows are not as user friendly as those that are, perhaps, available for other platforms.

blocks|key|747003|text|调查集市(bzr)。说真的这太神奇了。我见过最好的合并能力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|747004|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Look into Bazaar (bzr). Seriously, it is amazing. Best merge capability I've seen.

blocks|key|904248|text|试试看，安装麦斯吉特，然后|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|904249|git+svn+clone+svn://mysvn/repo/|code-block|syntax|javascript|904250|初学者Git+:实用指南中的一些资源应该有所帮助(特别是吉顿和吉特魔法+)。|904251|就我个人而言，我觉得git在一般情况下使用起来要愉快得多。大约两年前，我把我的个人SVN回复改为git，从来没有遇到过任何问题。|904252|不必担心您的SVN服务器是很好的(不需要不断的网络访问)，因此可以创建存储库(它们只是一个包含另一个.git文件夹的文件夹)，执行任何操作(提交、分支等等)，然后决定使用一两个简单的命令将代码放在Github上。|style|CODE|904253|它通常是“更快”(几乎每一个动作基本上是即时的)，一切都可以“离线”工作，克隆是完全的备份。但是我一直使用它的主要原因是Github|904254|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/msysgit/|1|https://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide|2|http://www.gitcasts.com/|3|http://www-cs-students.stanford.edu/~blynn/gitmagic/|4|http://github.com/^0|6|4|0|0|0|0|C|1|S|2|2|V|4|3|0|0|1E|4|0|1O|6|4|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|E|5|F|7|1C|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|1D|8|@]|9|@$A|1E|B|1F|1|1G]|$A|1H|B|1I|1|1J]|$A|1K|B|1L|1|1M]]|C|$]]|$1|K|3|L|5|6|7|1N|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|1O|8|@$A|1P|B|1Q|O|P]]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1R|8|@]|9|@$A|1S|B|1T|1|1U]]|C|$]]|$1|S|3|-4|5|6|7|1V|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]|10|$5|V|W|X|C|$Y|11]]|12|$5|V|W|X|C|$Y|13]]|14|$5|V|W|X|C|$Y|15]]|16|$5|V|W|X|C|$Y|17]]]]

Just try it, install <a href="http://code.google.com/p/msysgit/" rel="nofollow noreferrer">msysgit</a>, then

<pre><code>git svn clone svn://mysvn/repo/
</code></pre>

Some of the resources in <a href="https://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide">Git for beginners: The definitive practical guide</a> should be of help (<a href="http://www.gitcasts.com/" rel="nofollow noreferrer">Gitcasts</a> and <a href="http://www-cs-students.stanford.edu/~blynn/gitmagic/" rel="nofollow noreferrer">Git Magic</a> especially)

Personally I find git much more pleasant to use in general. I switched my personal SVN repos to git about two years ago and haven't had a single problem with it ever

Not having to worry about your SVN server is nice (no need for constant network access to it), so is being able to trivially create repositories (they're just a folder containing another <code>.git</code> folder), perform any operations (commit, branching etc etc), then decide to put the code on Github with a simple command or two.

It's generally much "snappier" (almost every action basically instant), everything works "offline", clones are complete backups.. but the main reason I keep using it is <a href="http://github.com" rel="nofollow noreferrer">Github</a>

blocks|key|904279|text|如果您习惯了Tortoise，那么您应该尝试Mercurial，它有一个具有类似的shell扩展龟HG的Windows。此外，乔尔·斯波斯基正在雾溪使用汞(根据他在播客中的说法)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|904280|这个软件包是完全独立的，我可以立即安装和使用Mercurial+(甚至不需要服务器！)|904281|entityMap|0|LINK|mutability|MUTABLE|url|http://www.selenic.com/mercurial/wiki/TortoiseHg^0|1C|3|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

If you are used to Tortoise SVN, then you should try Mercurial, which has a Windows package with a similar shell extension <a href="http://www.selenic.com/mercurial/wiki/TortoiseHg" rel="nofollow noreferrer">Tortoise HG</a>. Also Joel Spolsky is using Mercurial at Fog Creek (according to him in one of his podcasts).

The package is completely stand-alone, I was able to install and use Mercurial right away (doesn't even need a server!)

blocks|key|747222|text|在Windows和Visual+2008下，我以您描述的方式使用了这些系统：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|747223|目视源安全|unordered-list-item|747224|Subversion|747225|汞|747226|Git|747227|如果你珍惜你的生命，不要使用Visual+.|747228|747229|优点:优秀的工具，无论是在服务器端和客户端。VisualSVN和TortoiseSVN.|offset|length|747230|缺点:它不能很好地处理合并问题。|747231|747232|优点:极佳的合并支持，快速。|747233|缺点:+Windows工具几乎不存在，已经存在的GUI工具太可怕了，我希望我再也不用使用它们了。(我的意见)|747234|747235|优点:优秀的合并支持，良好的工具。TortoiseHG和VisualHG，基于Python的钩子脚本可以用Python编写，直接连接到HG中。|747236|缺点:工具与SVN不同。|747237|entityMap|0|LINK|mutability|MUTABLE|url|http://www.visualsvn.com/|1|http://tortoisesvn.tigris.org/|2|http://bitbucket.org/tortoisehg/stable/wiki/Home|3|http://sharesource.org/project/visualhg/^0|0|0|0|0|0|0|0|M|9|0|W|B|1|0|0|0|0|0|0|H|A|2|S|8|3|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|1J|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|1K|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1L|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1M|8|@]|9|@]|A|$]]|$1|M|3|F|5|6|7|1N|8|@]|9|@]|A|$]]|$1|N|3|O|5|D|7|1O|8|@]|9|@$P|1P|Q|1Q|1|1R]|$P|1S|Q|1T|1|1U]]|A|$]]|$1|R|3|S|5|D|7|1V|8|@]|9|@]|A|$]]|$1|T|3|J|5|6|7|1W|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1X|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1Y|8|@]|9|@]|A|$]]|$1|Y|3|H|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|Z|3|10|5|D|7|20|8|@]|9|@$P|21|Q|22|1|23]|$P|24|Q|25|1|26]]|A|$]]|$1|11|3|12|5|D|7|27|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|28|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A]]|1B|$5|16|17|18|A|$19|1C]]|1D|$5|16|17|18|A|$19|1E]]|1F|$5|16|17|18|A|$19|1G]]]]

I have used these systems in the manner which you describe, under Windows with Visual Studio 2008:
<ul>
<li>Visual Source Safe</li>
<li>Subversion</li>
<li>Mercurial</li>
<li>Git</li>
</ul>
If you value your life, do not ever use Visual Source Safe...
<h3>Subversion</h3>
<ul>
<li>Pros: Excellent tools, both on the server and client side. <a href="http://www.visualsvn.com" rel="noreferrer">VisualSVN</a> and <a href="http://tortoisesvn.tigris.org/" rel="noreferrer">TortoiseSVN</a>.</li>
<li>Cons: It doesn't handle merging things too well.</li>
</ul>
<h3>Git</h3>
<ul>
<li>Pros: Excellent merging support, fast.</li>
<li>Cons: Windows tools are almost non-existent, the GUI ones that do exist are so horrible, I hope I don't ever have to use them again. (my opinion)</li>
</ul>
<h3>Mercurial</h3>
<ul>
<li>Pros: Excellent merging support, decent tools. <a href="http://bitbucket.org/tortoisehg/stable/wiki/Home" rel="noreferrer">TortoiseHG</a> and <a href="http://sharesource.org/project/visualhg/" rel="noreferrer">VisualHG</a>, Python based - hook scripts can be written in Python, hooking directly into the HG api.</li>
<li>Cons: Tools are not up to the same par as with SVN.</li>
</ul>

blocks|key|2271508|text|是的，当然。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2271509|你误解了git是什么。我是说，你为什么会认为它只对团队有用？|2271510|如果您是一个单独的开发人员，git就更值得了。|2271511|优点：|2271512|svn要求服务器在后台运行。另一方面，git是一个简单的实用程序，您只需像运行grep或ls或任何其他简单的命令行实用程序一样运行它。您不需要设置任何服务器或类似的东西。|unordered-list-item|offset|length|style|CODE|2271513|.git文件夹是整个存储库，您可以随身携带它在任何地方(例如，在USB上)，并且它总是有您的回购。你的整个回购，连同它的历史，以及其他的一切，实际上都压缩得很好，所以它不会占用太多的空间。(提示:这就是git不需要服务器的原因；当您运行git命令时，git只会更改.git文件夹的内部)。|2271514|分支和合并非常容易。您可以在单独的分支上处理实验性的新特性，并且只有在其稳定时才能进行合并。同时，您可以在主分支上进行维护工作(例如，bug修复)，同时可以轻松地将主分支中的bug修复合并到您的实验性(主题)分支中。|2271515|这一点是主观的，但我发现这比svn容易得多。我尝试了一段时间使用svn，但发现它太复杂了，而且经常妨碍我(我不太记得什么是什么，为什么，我只知道这不是一次愉快的经历)。例如，重命名文件不是问题。您可以重命名文件，git不会大惊小怪，它只是不关心文件名。唯一的问题是，您必须记住在重命名它之后添加它，就好像您创建了一个新文件。|2271516|缺点：|2271517|视觉工具不多。有个鬼鬼祟祟的，不错，(我用得不多)，但你不想依赖它。您需要习惯于从命令行使用它。如果你习惯了使用svn的可视化工具，这可能是个骗局，但在我看来，这里唯一的缺点是，你必须走出舒适的区域去学习它；但相信我，这是值得的。|2271518|在windows上行结束可能存在一些问题，如果您是唯一的开发人员，这并不是什么大问题，但是如果您是在windows上开发的，而其他的是在linux上开发的，您需要确保所有文件都使用unix样式的行结束，而不是windows，以避免任何问题。|2271519|由于缺乏可视化工具，解决冲突(当它们出现时)可能会给一些人带来麻烦。我个人使用WinMerge，并在每个冲突文件上调用winmergeu+<conflictfile>命令来解决冲突。(注意:+WinMerge不是命令行合并工具，而是带有普通gui的可视化合并工具)。|2271520|这就引出了另一个问题。虽然git的启动非常容易，但对于以后出现的问题(如解决冲突)，可能会有一些学习曲线。如果您不分支和合并，那么您甚至不会遇到冲突，但您也将失去一个非常强大的功能。|2271521|更新：|2271522|我没注意到你在几台不同的机器上工作。|2271523|这没有什么区别，只要在切换到另一台机器时记住推拉，但是已经用svn:+commit/update完成了。|2271524|你将获得分支/合并的能力。别低估这种力量。|2271525|有多少次你想要实现一些疯狂的想法，但却从来不敢去做，因为你不想搞糟你的代码？吉特能让你摆脱这些忧虑。只需在一个分支中完成它，如果它成功了，将它合并到主分支，如果没有，删除这个分支并忘记它。|2271526|当然，您可能会说，您可以对svn+revert做同样的事情，在您开始疯狂的想法之前，可以返回到修订版。但是，如果您在此期间应用了bug修复，又会如何呢？如果你恢复你的疯狂想法，你将失去所有的错误修复/维护工作，你做的实验，你的疯狂的想法。|2271527|entityMap^0|0|0|0|0|13|4|18|2|0|0|0|0|0|0|0|1N|O|0|0|0|0|0|0|0|D|A|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1K|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1L|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1M|8|@$K|1N|L|1O|M|N]|$K|1P|L|1Q|M|N]]|9|@]|A|$]]|$1|O|3|P|5|J|7|1R|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1S|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1T|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1U|8|@]|9|@]|A|$]]|$1|W|3|X|5|J|7|1V|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|J|7|1W|8|@]|9|@]|A|$]]|$1|10|3|11|5|J|7|1X|8|@$K|1Y|L|1Z|M|N]]|9|@]|A|$]]|$1|12|3|13|5|J|7|20|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|21|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|22|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|23|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|24|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|25|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|26|8|@$K|27|L|28|M|N]]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|29|8|@]|9|@]|A|$]]]|1H|$]]

Yes, of course.
You're misunderstanding what git is. I mean, why would you assume it's only useful for teams?
git is even more worth it if you're a single developer.
<h2>Pros:</h2>
<ul>
<li>svn requires a server to run in the background. git on the other hand, is a simple utility, you just run it as if you're running <code>grep</code> or <code>ls</code> or any other simple command line utility. You don't need to setup any server or anything like that.</li>
<li>The .git folder is the entire repository, you can take it with you anywhere (for example, on a USB stick) and it will always have your repo. Your entire repo, along with its history, and everything else, and it's actually compressed very well, so it doesn't take that much of space. (Hint: that's why git doesn't need a server; when you run git commands, git just changes the internals of the .git folder).</li>
<li>Branching and merging is really easy. You can work on experimental new features on a separate branch, and only merge when its stabilized. Meanwhile, you can do maintenance work on the master branch (e.g. bug fixes) and all the while you can keep merging the bug fixes from the master branch into your experimental (topic) branch with ease.</li>
<li>This point is subjective, but I find it much easier than svn. I tried to use svn for a while, but found it too complicated, and often it got in my way (I don't exactly remember that what's and why's, I just know it wasn't a pleasant experience). For example, renaming files is not an issue. You can rename files and git won't make any fuss, it just doesn't care about the file name. The only thing is, you have to remember to add it after you rename it, it's as if you created a new file.</li>
</ul>
<h2>Cons:</h2>
<ul>
<li>Not many visual tools. There's a git-gui, it's not bad, (I haven't used it much) but you don't wanna depend on it. You need to get used to using it from the command line. If you're used to visual tools with svn, this maybe a con, but in my opinion, the only con here is that you have to step a little bit out of your comfort zone to learn it; but trust me it's worth it.</li>
<li>There maybe some issues with line-ending on windows, it's not a big problem if you're the only developer, but if you're developing on windows and others are developing on linux, you need to make sure that all files use unix-style line ending instead of windows', in order to avoid any issues.</li>
<li>Due to lack of visual tools, resolving conflicts (when they appear) might be trouble some at first. I personally use WinMerge, and invoke the command <code>winmergeu &lt;conflictfile&gt;</code> on every conflict file, to resolve conflicts. (Note: WinMerge is not a command-line merge tool, it's a visual merge tool, with a normal gui).</li>
<li>This brings me to another point. While it's really easy to get started with git, there maybe some learning curve to dealing with issues that come up later (such as conflict resolution). If you don't branch and merge, then you won't even run into conflicts, but then again you'll also be missing a very powerful feature.</li>
</ul>
<h3>UPDATE:</h3>
I didn't notice the bit about you working from several different machines.
It doesn't make a difference, you just have to remember to push and pull whenever you switch to a different machine, but you already do this with svn: commit/update.
You'll get the power of branching/merging. Don't under-estimate this power.
How many times have you thought of implementing some crazy idea, but never dared to do it because you don't want to mess up your code? git relieves you from these worries. Just do it in a branch, if it works out, merge it to the main branch, if it didn't, delete the branch and forget about it.
Sure, you might say that you can do the same with <code>svn revert</code>, reverting back to the revision before you started the crazy idea. but what if you had bug fixes applied in the meantime? If you revert your crazy idea, you'll lose all the bug fixes/maintenance work you did while experimenting with your crazy idea.

blocks|key|905313|text|除了已经说过的话，如果您是一个单独的开发人员，并且没有经历过SVN方面的麻烦，我认为没有理由切换。svnserve+(守护进程)在本地工作正常(我有OS+)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|905314|与Git工具TortoiseSVN…相比，…是一件好事。你有什么特别的理由想远离颠覆吗？|905315|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Apart from what has already been said, If you're a single developer and haven't experienced troubles with SVN I see no reason to switch. svnserve (the daemon) works fine locally (I have OS X). 

TortoiseSVN is a blessing compared to Git tools… is there any particular reason why you'd like to move away from Subversion?

blocks|key|747299|text|不久前，我从svn转到了Git。我同意上述几个关于Git分布式体系结构优于svn的优点的答案(比如我可以在记事本上带着我的回购)，但更有说服力的原因是更普通的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|747300|Svn非常麻烦，它到处都是他的东西(.svn文件夹)。这使得在.svn存储库中很难使用通用命令行工具，如grep+(和许多其他工具)。在我的项目中，我也有一些安装过程，需要将一个完整的重新源树复制到某个系统路径。在使用svn时，我必须编写额外的代码(或导出存储库)，以避免我的安装过程也复制.svn。那种问题用Git就完全消失了。它们都位于存储库根目录下的one+.git目录中。|unordered-list-item|offset|length|style|BOLD|747301|现在(2/2013)根文件夹中只有一个.svn文件夹！|747302|我在Linux上使用我的svn客户端有过一些糟糕的经验，看起来很简单的操作，比如移动一个文件，然后在提交之前修改它，使用100%25的CPU导致系统挂起！(不，造成坠机的不是其他原因，我可以随意重复一遍)。Git工具从来没有遇到过这样的问题。|747303|在以前的svn存储库中，我也有过在主干和稳定分支之间合并代码的糟糕时期。和吉特在一起真的更容易。|747304|现在，我做了这个动作，因为我真的觉得使用svn很糟糕，如果它对您有效，那么就没有迫切需要改变的必要了。程序员的真正任务是处理代码，存储库只是一些工具，至少不应该妨碍他的工作。这正是svn不适合我的原因。|747305|entityMap^0|0|4Y|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@$E|U|F|V|G|H]]|9|@]|A|$]]|$1|I|3|J|5|6|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|X|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|Y|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Z|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|R|$]]

Some time ago I did that move from svn to Git. I agree with several of the above answers about advantages of Git distributed architecture over svn (like ability to take my repo with me on my notepad), but the compelling reasons were much more mundane.

<ul>
<li>Svn is quite cumbersome, it puts his things (.svn folders) everywhere. That makes hard to use common command line tools like grep (and many others) on .svn repositories. In my project I also had some installation procedure that needed to copy a full ressource tree to some system path. When using svn I had to write extra code (or export repository), just to avoid that my installation procedure also copy .svn. That kind of problems totally disappeard using Git. All is in one .git directory at root of repository.</li>
</ul>

Nowadays (2/2013) there is only a single .svn folder in root folder present!

<ul>
<li>I had several bad experience with my svn client on Linux, seemingly simple actions like moving a file and then modifying it before committing caused system hangup using 100% CPU! (And no, it was not something else that caused the crash and I could repeat it at will). Never encountered such problems with Git tools.</li>
<li>I also had some terrible times merging code between trunk and stable branch on my old svn repository. It's really easier with Git.</li>
</ul>

Now, I made that move because I really felt bad using svn, if it works for you there is really no compelling need to change. The real task of a programmer is working with code, repositories are just tools that should at least not get in his way. And that was exactly why svn didn't worked for me.

--- THIS THREAD IS VERY LIKELY OUTDATED AS OF 2013 ---

Is it worth going to GIT from SVN when the repositories are mainly accessed by a single developer? I have several machines that I use for development and not mainly develop in C#. But I have a mix of VB, VB.Net, PHP, C#, C++, HTML, Batch, BASH and many more in my repositories. What, if anything, will I gain by migrating to GIT from SVN? Right now use TortoiseSVN + VisualSVN Server with a set of central repositories and several client machines. While I have granted a few friends access to my repositories they do not Update or Commit often (if ever).

Also is there a way to have the flexibility and ease of maintenance I get with VisualSVN Server + TortiseSVN with Git?

((I'll bite... what other platforms and trickery would be compelling for a single developer/small group?)

Please List Pros and Cons not just one sided opinions.

Current Tool Chain...
Visual Studio 2008 (C#/VB.Net) + TortoiseSVN + VisualSVN 

Main Focus...
XNA Games, WCF/Socket Services, Web Development

Is it worth going to Git from SVN for a single developer?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

--这个线程很可能在2013年就过时了--当存储库主要由单个开发人员访问时，是否值得从SVN访问GIT？我有几台用于开发的机器，而不是主要在C#中开发的。但是我的存储库中包含了VB、VB.Net、PHP、C#、C++、HTML、批处理、BASH等多种语言。如果有的话，从SVN迁移到GIT会得到什么好处呢？现在，将Tor...

问对于单个开发人员来说，从SVN到Git值得吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于单个开发人员来说，从SVN到Git值得吗？EN