我为一个使用Subversion作为主要VCS的团队工作,但几乎每个人都开始通过git-svn在本地使用git.现在我们正在考虑完全转换为git.
作为一个中间步骤,最好同时使用它们两个.问题不在于那些非常乐意切换到git的用户,而是我们围绕Subversion构建的持续集成/构建基础架构.管理当然不会对任何大爆炸导致的停机时间感到激动,我们每两周发布一次新功能,几乎每天都会发布错误修复和其他小问题.理想情况下并行运行这些系统会使最终的开关成为无问题.
问题似乎是不存在源自Subversion存储库的共享git存储库.每个并行git svn merge/rebase都会创建新的git提交,这些提交都是重复的.并行我指的是两个开发人员在他们自己的同一个git存储库的克隆中进行合并或重组.更糟糕的是,git svn dcommits似乎改变了git commit的ID.
那么这种环境是否可能,或者git-svn真的只是一个单用户工具？
首先,我建议不要费心去尝试做两个中央存储库,一个svn和一个git,当然不能用svn作为核心存储库.SVN倾向于忽略git的哈希提交标识,因此它不是一个简单的双向街道.
现在更好地咬紧牙关,而不是以后处理混乱.
svn的一个目的是我可以看到有效,如果对于继续的svn用户不是非常有用,则作为只读存储库.换句话说,您可以设置svn来镜像git存储库(至少是主分支),允许checkout,但不允许提交回svn.这样,如果有人想要审查代码或行为,并熟悉svn或svn工具,他们就可以利用这些知识.他们只是不会处于完全开发模式.
使用svn而不是git的原因主要是熟悉,所以你最好的选择可能是A:
教育一个基本的命令集,允许有人将他们最重要的行为从svn心态转换为git用法(http://git.or.cz/course/svn.html).这样他们可能没有做到git提供的最好的东西,但是他们将能够做到需要获得git承诺的简单基础知识.
和B:
代表一段时间.虽然有些人正在学习git,但是让他们在更加知识渊博的git用户上游提供补丁/分支以合并功能,并协助他们,直到他们能够快速熟悉该工具.
最后,没有太多关于ftp是svn的事实,因为svn是git,为了利用这些优势,你需要完全采取行动.
| 归档时间： |
|
| 查看次数： |
336 次 |
| 最近记录： |