基本上我想在不推送它们并且不切换分支的情况下进行我的更改。这允许我做一些工作,commit
当我在一个好的停止点时,然后继续在同一个分支中工作。如果我搞砸了,我可以revert
,如果我添加新的更改,我可以commit
再次。
我意识到我可以在 SVN 中创建一个功能分支来跟踪这些更改,但同样,我想这样做,同时保持在同一个分支/主干中。即使是等价的git stash
也足够了,尽管 SVN 似乎没有这个功能。
基本上我想在不推送它们并且不切换分支的情况下进行我的更改。这允许我做一些工作,commit
当我在一个好的停止点时,然后继续在同一个分支中工作。如果我搞砸了,我可以revert
,如果我添加新的更改,我可以commit
再次。
我意识到我可以在 SVN 中创建一个功能分支来跟踪这些更改,但同样,我想这样做,同时保持在同一个分支/主干中。即使是等价的git stash
也足够了,尽管 SVN 似乎没有这个功能。
分布式版本控制的关键在于本地提交的这一特性,它可以在以后与上游存储库合并。SVN 不是分布式的,做不到。主要障碍是 SVN 的线性修订编号,这意味着每个客户端都必须为每个变更集获取一个新的识别修订号。由于“分配”一个修订号并在以后使用它会导致各种竞争条件,“提交”和“推送”操作在 SVN 和每个非分布式版本控制系统中都是原子的。
话虽如此,git 的 SVN 前端是一个不错的选择,就像 Joe 建议的那样。它确保 SVN 永远不会看到您的本地个人提交,并且“推送”被转换为单个大型 SVN 提交。
按照设计 SVN 没有,但是您可以使用 git 的git svn
命令作为 SVN 的前端。它允许您从 SVN 远程执行推/拉工作,但仍然在本地使用 git,因此无需推送到 SVN 存储库即可进行本地提交。
这样的事情可能会有所帮助: http: //www.viget.com/extend/effectively-using-git-with-subversion/
您也许可以使用被子来执行此操作,尽管如果您只想将部分被子队列提交给 svn,它会变得很棘手。