Git作为常规工作流导入/导出到SVN?

这是一个主观的问题,但是的,它是 绝对值得

作为一个极端的例子,如果您在本地使用Subversion,并且意外地删除了一些尚未提交的文件(例如,可能您在一个平面上,无法提交),那么您就丢失了所有的工作。在Git上,因为您的存储库是本地的,所以您只需

git ls-files -d | xargs git checkout --

沙波!您的文件已还原。

如果您没有习惯于将自己的工作私下提交给自己的私人分支,而不影响其他任何人,那么您就没有充分利用版本控制的功能。Git让这一切变得非常简单——可能比任何其他风投和 方式 比SVN容易。

它还允许您轻松地将与当前正在做的工作无关的更改(例如,您注意到一个无关的bug)作为单独的提交提交。你 做 相关的 变化,不是吗?也许没有其他风投能像git那样简单。过去与其他VCSE的经验告诉我,开发人员通常会变得太懒,倾向于一起提交不相关的更改。。。如果其中一个更改需要恢复,则会变得很痛苦。有了git,懒惰是很难证明的。您甚至可以在使用提交更改之前单独测试更改 git stash --keep-index . 如果您只使用过SVN或类似的工具,那么像这样的功能和灵活性几乎是无法想象的。

再加上所有其他git铃铛和口哨,比如:重定基址, git bisect (在回归测试/调试期间可能是一个真正的天赐之物), git send-email (用于快速通知队友您将要做出的承诺),离线工作 速度 git grep (用于搜索受版本控制的文件), git blame (可能是最好的“责备”工具),实际 实用的

出于这些和其他原因,我和我团队的其他一些成员使用git svn作为svn的前端,我无法想象用其他方式来实现它。。。嗯,除了可能只使用git而不使用任何SVN之外:P

当您被锁定在Subversion中时,git svn是完全值得的。我认为单是隐藏功能就让事情变得非常美妙。此外,您可以使用Git与同事共享,而不必与subversion服务器建立恒定的连接,如果是异地连接,则连接速度通常会很慢。

有几个人在工作,他们也这样做,我们当地的SVN服务器。他们似乎认为这会增加很多价值。它允许他们将可能是问题修复、重构和基于sytle的更改的混合工作分割和更改为不同的问题,即使这些更改是同时进行的。

我刚刚让他们建立了一个git回购协议,所以我也可以在场外工作。

另外,这对于责备/回顾时间任务来说是更好的方式。

这正是我使用subversion的方式,因为它给了我如此多的灵活性和速度。我喜欢在本地机器上创建一大堆功能分支,并将它们合并回主干中,而不会污染服务器。

• 轻量级局部分支
• git add -p
• git stash
• 能够与同样以这种方式使用Git的同事共享补丁甚至分支(在提交Subversion之前)