web项目的版本管理

关于版本管理，很多人都会想到svn,git,hg这些软件，但这些软件只是一个版本工具。但怎么管理？还是靠规则和流程。

 

我们的项目一开始就使用svn来管理版本库。但一开始也没考虑，直接在版本库的根目录下建立项目。这样会产生什么问题？

 

•  大型改版时不能对已上线程序进行修改。
  • 如：在上线某个版本后，程序进行量的修改或新增功能，时间也比较长。在这样的开发时，如果已上线的版本发现有问题。将只能直接修改上线的程序，脱离的版本管理
• 同事之间修改的文件。容易冲突(
  • 程序员A,修改某几个程序，没有修改完他下班时把文件都提交了。程序员B，第二天来的上班时，更新了一个版库，结果发现不能运行，查了N多问题好找发现原来程序员A提交的文件所影响到

出现这样的问题，回头再看一下别人是怎么做。branches、tags、trunk会很快进入我的眼球。

 

• branches 作为分支，对于新功能或者容易产生冲突的修改都从trunk建立一个分支到branches下。
• tags 发布过的版本，起标记的作用
• trunk 主线，正运行的版本

 

 回到上面的问题，我会希望：

 

• 新增功能或大面积修改程序时，不会影响到已经上线的版本修正
• 程序员可以随便提交文件，而不影响其它同事。

 

 看来前人的经验还是很不错的。但还是需要根据实际情况修改一下。

 

• trunk 上线的版本，即与线上的代码完全一致。
• branches/main 作为正常开发的版本目录。  
• branches/devA 程序员A的版本库（如果是git或hg即不需要）
• branches/devB 程序员B的版本库 （如果是git或hg即不需要）

 

 其它的目录就不需要了，如tags。总一下开发的版本管理流程

svn：

 

1. 开发版本的总库是 branches/main ，必须保证提到或合并到这里的版本已经是可以运行的。
2. 建立每个程序员的版本，从branches/main里分出来
3. 程序员可以独立开发程序并提交自己的代码
4. 完成某个功能后，必须先提交自己的分支上， 
5. 合并到branches/main版本库，然后再获取branches/main的内容
6. 中间如果同事间需要合作开发，可以修改另外新建一个共同使用的分支。 
7. 需要上线时，把branches/main 合并到trunk上。

 

 git或hg

 

1.  开发版本库的总库branches/main 必须保证提到或合并到这里的版本已经是可以运行的。
2. 每个程序员的内容都提到本地的版本库里，如果需要合作开发，才建立分支
3. 在完成全部程序后，才提交文件到branches/main上。
4.  需要上线时，把branches/main 合并到trunk上。

 

 从这样看分布式管理确实比较方便。

 

 

转载于:https://www.cnblogs.com/zsphper/archive/2012/05/05/2485124.html