如何进行项目版本控制？

0 0

如何进行项目版本控制？5

现在摆在我面前的有几个问题，想咨询一下大家，
看看大家在平时的时候如何解决这类问题
1，项目开发时有一个svn版本库，大家一起提交代码和更新
后续开发的差不多了，客户要求上线，但是上线以后会有bug，同时项目
还有新的功能要开发，
如何大家现在共用一个版本库的话，会出现新功能还没有测试完成，
但是bug是要及时修复，所以要着急发版。

所以如何控制版本库，能够及时的修改和修复bug，同时对于新功能的开发还可以有条不紊的进行，
同时对于发版不会因为新功能的开发代码提交而导致bug即使修复完成了也没有办法发版（因为新功能还没有开发完，只是提交了部分代码）。

项目管理

2014年7月17日 14:25

moonlight2010
20
0 0 2

9个答案按时间排序按投票排序

0 0

楼主可以借鉴一下，我们项目管理方式。
svn根目录
Trunk：主开发目录。
Branches：分支开发目录及测试目录，版本正式发布并生成tag后删除。
Tags：已发布版本（包括补丁）的存档目录，不允许修改。
Release：程序发布目录，含运行程序、升级脚本和标准库。由配置管理员在版本发布时创建。

trunk
Bin：运行程序存放路径。
Control：第三方控件存放路径。
Documents：产品开发文档存放路径。
Management：项目管理类文档存放路径。
Procedure：存储过程或包、初始化数据及视图存放路径。
Script：数据库升级更新脚本存放路径。
Sources：源代码存放路径。
Tools：工具存放路径

Branches
一级目录为程序修改版本标识，二级目录的目录结构与trunk一致。

Tags
一级目录为已发布程序基线版本号，二级目录为子版本标志，比如BL表示基线版本，sp1表示对应基线的第一个大补丁版本呢，三级目录的目录结构与trunk一致。

Release
一级目录为已发布程序基线版本号，二级目录如下：
Bin：执行程序存放位置。
Bin\Doc：操作手册、安装手册及升级说明存放位置。
Patch：补丁存放位置
Procedure：存储过程或包、初始化数据及视图存放位置。
Script：数据库升级更新脚本存放位置。
Stddb：标准库存放位置

2014年7月19日 21:46

mengjunquan
90
0 0 6

添加评论

0 0

我们会经常性的遇到这种问题。
先说我们的svn 结构：
开发在branch 分支，当前线上稳定版本在trunk，每次大版本发布，会在release 分支上建立一个tag。

当线上环境遇到bug 而有一个或多个开发分支存在的时候，可以如下进行：
1、一般此情况为紧急bug，直接在trunk 上进行修改
3、将trunk 的改动，在提交前利用svn 的patch 功能，导出改动的patch
2、测试通过后紧急上线fix，线上验证改动有效
4、将第2步得到的patch 覆盖到所有的开发分支上，有必要的话，覆盖到release 分支上。

其实，如果能够灵活利用svn diff 命令，流程还可以更加优化。

2014年7月19日 14:06

schweigen
145
0 0 4

添加评论

0 0

svn上面有这个功能，采用建立多个分支的方法，你把还在开发的项目放到trunk分支下，在这里进行功能增加和修改，把上线的项目放到release分支下，每增加或修改bug后把这两个分支merge一下，然后重新发布到release分支下

2014年7月19日 12:12

如若_晴
32
0 0 8

添加评论

0 0

楼主的想法我想是大多数开发人员都会遇到的问题。楼上的朋友说的是有道理。我这里补充下，华为最近几年在项目开发上都一直推敏捷模式，追求每日构建，版本的更新迭代快，可以参看我的文章，SVN中如何给项目打基线 http://rmzdb.iteye.com/admin/blogs/1851220，打基线的目的就是要知道每个版本出去的代码原样，bug提交后再新版本引入是否会有冲突等。每次迭代后，基线就向后推，最终朝着终极版本前进，当然，有时候也要灵活处理。

2014年7月17日 23:13

rmzdb
170
0 0 17

添加评论

0 0

楼主的问题我也遇到过，这个问题还是要和一起开发的兄弟们商量，分支也是一个好方法

2014年7月17日 20:32

Forever2013
20
0 0 2

添加评论

0 0

基于楼主项目情况，建议使用SVN的分支。
我之前负责项目的情况和楼主很相似，用户催着上线、改bug，一边还有新功能要开发。

结合自己项目的情况，使用SVN分支方式如下：
首先找一个切入点，定义主干。我项目把主干定义为：与正式库运行项目完全一致（就像正式系统的影子），目的是方便修改bug，排查问题。
当用户反馈正式系统有bug，那么就从主干上打出分支，在分支上改bug。待测试通过。把这个分支上线，同时主干合并该分支。其他分支合并主干（保证bug在svn范围内都被修复）。
若有新的需求准备开发，则在主干上打出新分支，在新开的分支上开发。

大体就是这样，这里有几点楼需要掌控：
开发前尽量估算出交付的时间，将交付时间差不多的需求，在一个分支上开发，减少分支数量。主干不允许任何人提交代码，除了合并分支。保证主干和正式系统的一致性。

SVN分支管理的方式，希望楼主能根据项目实际情况灵活运用，毕竟方法是活的！

2014年7月17日 17:06