我的许多同事在1-5人的小组中使用SVN,部分工作在特定项目上.其中一半是没有经验的学生.事实上,我们不是真正的软件开发人员,具有一年的经验.他们中的大多数使用Eclipse和subclipse来读取和写入他们对SVN存储库的贡献.
他们中的一些人有以下不同的问题:
签出(与更新和合并混淆)
提交(与更新混淆)
更新(与提交和签出混淆)
合并(是最难的.什么是合并?我必须将我的代码合并到SVN中吗?)
如果他们按错了按钮,他们担心SVN可能会杀死他们的工作(他们不称之为工作分支).
在将一些任意库依赖项添加到其java项目之后,他们将eclipse .project文件提交到存储库.其他同事从这些comitts得到编译错误,并发现很难解决这些问题.
一般来说,他们说:我想在没有SVN的情况下工作,我不喜欢它.这太复杂了.
有没有像"SVN for kids"这样的电子学习项目?我怎样才能让它们像版本控制一样?
根据我的经验,这么多人"害怕"或不喜欢版本控制的主要原因之一是因为他们不了解基本概念以及系统如何工作.不幸的是,对于许多有经验的开发人员来说,这也是如此.我知道多年来一直使用CVS和Subversion的人,但他们从不创建分支或标签,因为他们不了解它们是如何工作的,因此将它们视为"复杂"或"不必要".
我认为您的同事必须基本了解版本控制的目的,使用它的原因以及执行此操作所涉及的工作流程.就个人而言,我认为Subversion书的前两章提供了对所涉及的概念和版本控制系统背后的理论的最佳解释,因此我建议你的同事阅读这些.
我不建议使用IDE集成来学习使用版本控制.集成和插件通常会隐藏系统的"细节",这可能会非常混乱,特别是如果您不知道"引擎盖"之类的东西.
我更喜欢像TortoiseSVN这样的工具,你可以直接执行大多数操作,也可以手动操作,在幕后没有任何"魔法".例如,一个非常常见的误解是不了解工作副本与服务器上的存储库之间的差异.我经常看到,切换到直接在文件系统上运行的工具将有助于解决这种情况,因为用户被迫主动思考他在做什么,以及为什么.
与生活中的其他一切一样,使用版本控制也是最好的个人经验 - 尝试和失败,并再次尝试.这就是我建议为每个人创建沙箱主文件夹的原因.允许他们在系统中试验各种功能,而不必担心破坏项目中的任何内容或丢失数据.
首先,您需要采用"独立于软件"的方法来研究这个问题.不要强迫他们阅读Red Bean书籍,或者尝试告诉他们所有漂亮的SVN命令.相反,您应该首先尝试使用版本控制来教授正确的工作流程.简而言之,这意味着:
更新您的视图
做一些改变
测试你的代码
再次更新
如有必要,解决合并冲突
承诺
请注意,我将排除初始签出流程,因为您应该在那里帮助他们查看他们的初始视图.上述步骤只是SCM支持的开发人员每天应该做的事情(顺便说一句,你也应该真正强调这一点,否则那些担心合并冲突的人只会随着时间的推移而变得更糟).
SCM成功采用的关键是双重的; 首先,您需要让人们习惯使用软件来处理正常的,非痛苦的事情(即更新/提交).如果你不这样做,那么开发人员将倾向于避免使用SCM,直到你为此烦恼并询问为什么他们在两周内没有提交任何代码.其次,你需要教会人们如何克服可能导致他们失去工作的常见痛苦场景.
SCM系统确实可能会破坏工作,并且通常在任何事件通过合并冲突提交到存储库之前发生.你应该模拟合并冲突,让他们解决它们,然后让它们自己做同样的事情.你应该解释一下:
冲突后,.r1,.r2,.mine和原始文件的含义是什么?
演示如何以图形方式解决冲突
现在重新编译并再次测试软件以确保
再次备份.mine文件,以确保
然后提交
境内有许多SCM更复杂的事情,而这只能解释很久以后后的基础是很好理解的.甚至不用提及合并或标记或类似的东西,直到他们有几周的日常经验.否则,复杂性和额外的风险将使这个新工具对他们来说更加"无用".
同样,这里的关键是以软件中立的方式强调日常SCM工作流程,并慢慢解释特定SCM系统出现时的怪癖.合并是唯一需要首先解释的复杂因素,因为它可能是每天遇到的唯一痛苦的事情.其他所有内容都应该在出现时加以解释.
对于所需程序的简单"备忘单",一步一步给出,是最好的方法.SVN确实有一些不明显的陷阱.我已经参与了使用它的新人,有时他们会从当前版本中删除整个代码块等等.当然,你总是可以回过头来获取以前的版本,但是SVN 是可怕的和危险的新人.牢记这一点,并为所需操作编写非常简单但明确的说明!
"我怎样才能让它们像版本控制一样?"
删除他们的工作副本,他们将很快掌握有用的版本控制软件!
说真的,使用VCS与成熟的开发人员携手并进.如果你不知道为什么你想要Subversion,我不会相信他们是开发者.他们可能有技能编程,但编程只是开发人员工作的一部分.
我确实相信,在你丢失代码之前,你真的永远不会欣赏VCS.