史上最全SVN使用总结,建议先收藏后观看(2),前端开发规范文档

本文详述了SVN的各个操作,如Checkout、Update、Revert、Merge、Commit等,强调了版本控制在前端开发中的重要性,并提供了创建版本库、配置权限的步骤。此外,还介绍了如何解决冲突和回退版本,最后分享了前端开发的学习资源和面试题集。
摘要由CSDN通过智能技术生成

Checkout 操作是用来从版本库创建一个工作副本。工作副本是开发者私人的工作空间,可以进行内容的修改,然后提交到版本库中。

更新

顾名思义,update 操作是用来更新版本库的。这个操作将工作副本与版本库进行同步。由于版本库是由整个团队共用的,当其他人提交了他们的改动之后,你的工作副本就会过期。

让我们假设 Tom 和 Jerry 是一个项目的两个开发者。他们同时从版本库中检出了最新的版本并开始工作。此时,工作副本是与版本库完全同步的。然后,Jerry 很高效的完成了他的工作并提交了更改到版本库中。

此时 Tom 的工作副本就过期了。更新操作将会从版本库中拉取 Jerry 的最新改动并将 Tom 的工作副本进行更新。

执行变更

当检出之后,你就可以做很多操作来执行变更。编辑是最常用的操作。你可以编辑已存在的文件,例如进行文件的添加/删除操作。

你可以添加文件/目录。但是这些添加的文件目录不会立刻成为版本库的一部分,而是被添加进待变更列表中,直到执行了 commit 操作后才会成为版本库的一部分。

同样地你可以删除文件/目录。删除操作立刻将文件从工作副本中删除掉,但该文件的实际删除只是被添加到了待变更列表中,直到执行了 commit 操作后才会真正删除。

Rename 操作可以更改文件/目录的名字。"移动"操作用来将文件/目录从一处移动到版本库中的另一处。

复查变化

当你检出工作副本或者更新工作副本后,你的工作副本就跟版本库完全同步了。但是当你对工作副本进行一些修改之后,你的工作副本会比版本库要新。在 commit 操作之前复查下你的修改是一个很好的习惯。

Status 操作列出了工作副本中所进行的变动。正如我们之前提到的,你对工作副本的任何改动都会成为待变更列表的一部分。Status 操作就是用来查看这个待变更列表。

Status 操作只是提供了一个变动列表,但并不提供变动的详细信息。你可以用 diff 操作来查看这些变动的详细信息。

修复错误

我们来假设你对工作副本做了许多修改,但是现在你不想要这些修改了,这时候 revert 操作将会帮助你。

Revert 操作重置了对工作副本的修改。它可以重置一个或多个文件/目录。当然它也可以重置整个工作副本。在这种情况下,revert 操作将会销毁待变更列表并将工作副本恢复到原始状态。

解决冲突

合并的时候可能会发生冲突。Merge 操作会自动处理可以安全合并的东西。其它的会被当做冲突。例如,“hello.c” 文件在一个分支上被修改,在另一个分支上被删除了。这种情况就需要人为处理。Resolve 操作就是用来帮助用户找出冲突并告诉版本库如何处理这些冲突。

提交更改

Commit 操作是用来将更改从工作副本到版本库。这个操作会修改版本库的内容,其它开发者可以通过更新他们的工作副本来查看这些修改。

在提交之前,你必须将文件/目录添加到待变更列表中。列表中记录了将会被提交的改动。当提交的时候,我们通常会提供一个注释来说明

介绍SVN各个目录使用规范 Svn目录使用规范 TortoiseSVN客户端工具 选择创建SVN目录结构的选项(生成trunk、branches、tags目录),如下图: 1、 trunk是主分支,是日常开发进行的地方。 2、branches是分支。一些阶段性的release版本,这些版本是可以继续进行开发和维护的,则放在branches目录中。 3、tags目录一般是只读的,这里存储阶段性的发布版本,只是作为一个里程碑的版本进行存档。 注:在这需要说明下分三个目录的原因,如果项目分为一期、二期、三期等,那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches上,这样二期开发的代码就对一期的代码没有影响,如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码,如果用户使用的过程中发现有bug,则只要在branches上修改该bug,修改完bug后再编译branches上最新的代码发布到生产环境即可。tags的作用是将在branches上修改的bug的代码合并到trunk上时创建个版本标识 Trunk目录:Doc(文档库,放项目相关文档类)、sourcecede(代码库) Doc目录下按项目存放文档,以下以proj1为例做说明 Proj1----项目名 1、Controlled------组织级scm建一个名为controlled的目录,当项目某文档通过评审后,组织级scm从项目目录下找到那文档,复制到controlled目录下。(一般用不到) 2、Develop---开发文档 2.1、Design----设计文档 2.1.1、DbDesign---数据库设计文档 2.1.2、HLD---概要设计 2.1.3、InterfaceDesign---接口设计 2.1.4、ServiceDesign---服务设计 2.2、REQ---需求文档 2.3、SRS---软件需求规格说明 2.4、Test---测试文档 2.4.1、Review---可空 2.4.2、TestCese---测试用例 2.4.3、TestDoc---测试文档 2.4.4、TestEnv---测试环境说明 2.4.5、TestReport---测试报告 3、Document---项目文档 4、Management---管理文档 4.1、Meetings--会议纪要 4.2、PIM--- 4.3、Plan---计划 4.3.1、review 4.3.2、SDP---软件开发策划文档 4.3.3、SPP---软件项目策划文档 4.4、report---报告 4.4.1、Milestonereport---版本报告 4.4.2、ProjectTrackReport---项目跟踪报告 4..4.3、SCM---软件配置管理文档  4.4.4、SQA---软件质量保证计划 4.4.5、项目周报 4.5、Sow---工作说明书 4.6、Summarize---总结 4.7、Template---模板 4.8、Trainning---培训文档 打标签/分支有两种方式: 1、选中项目,就是trunk下的本地项目,右击,选中Branch/Tag,出现如下对话框。 下图中的配置完成了之后,点击OK即可完成“打标签/分支”。 2、直接在SVN上在对应的标签/分支目录下创建对应的版本文件夹,将trunk下稳定版本的代码直接copy到对应的文件目录下即可。
[本地工作区] :work copy ,本地工作副本; [主项目]:引用共用模块的新项目(工程) 最新版本(HEAD revision):版本库里文件或目录的最新版本 SA :SVN服务器的管理员 PRA :单个项目库的管理员,或者是项目负责人 User :普通工作人员 WC :work copy ,本地工作副本 1. 版本控制原则 SVN(或者其他版本控制软件)只是一个版本控制的辅助工具,不可能把所有的问题都自动解决掉。尤其,对于冲突这个麻烦事儿,项目成员在项目进程中要尽量通过优化流程来解决,而不是将希望寄托于软件工具来自动解决一切问题。 建议的开发过程组织: 1. 随行就市 项目刚开始阶段,单独开发;项目稳定阶段,完整开发。项目开发初期,各个项目成员负责自己的文件夹(或者模块),与SVN服务器间的更新、提交等操作只需要针对自己负责的文件夹(或者模块)就行了,他人的文件夹(或者模块)可以不必关心;项目稳定阶段,也就是每天的变更量很小了,所有项目成员与SVN服务器的更新、提交等操作需要针对项目的所有文件夹(或者模块),各个项目成员在其本地编译时本地工作区的全部项目程序(或者资料)均为最新的版本,保证项目作为整体能够顺利运行。 2. 能躲就躲 尽量保证一份文件只有一个项目成员在编辑。举例说明:程序员A负责底层中文件 DBAccess.cs的编写,如果程序员B的工作要求他为DBAccess.cs增加两个方法,程序员B应该通知程序员A来增加而不是自己增加;如果此时A非常繁忙需要B自己增加,就需要B更新本地的DBAccess.cs,然后开始修改,修改完成后立即提交并通知A更新本地的文件,通过缩短提交间隔来减少冲突。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值