标准化篇(一) 小公司也应该下决心使用SVN(GIT)分支管理

Step-by-step guide

目录：

1. SVN目录介绍
2. Why branch?
3. How to build branch & merge?
    

一、SVN目录介绍

说明：

ProjReposi： 代码仓库，名字可能是公司名+Repository、项目组+Repository、项目名+Repository

Proj1(Proj2)： 项目名，例如：erp / crm

trunk： 代码主干目录，存放源码【项目开发最初可基于trunk开发】

branches： 分支目录，存放源码对应的分支版本，项目每次发布后，会拉取对应的分支版本(e.g: erp_rel_v1.0 / erp_rel_v2.0),此后严格基于分支开发

tags： 版本基线，项目发布之后，应当打基线(tag)存档，如果在下一个发布版本前发现线上版本有bug，就需要恢复tag对应的版本，在上面进行紧急修复，避免因为现有分支代码的改动污染线上环境。

二、Why branch?

图1 基于trunk的版本迭代

图2 基于branch的版本迭代

图1中是大部分团队采用的方式，在trunk（主干目录）开发，在一份代码上不断迭代，并没有版本概念，如果发现线上版本（例如v2.7）发现致命bug，但是现有代码又做了很多改动怎么办？答：真不好办。

图2中展现了引入分支后的版本管理路线，好像很牛x的样子，解决了版本切换、多条线开发(e.g：erp_chengdu, erp_bejing, erp_guangzhou)的代码管理痛点。

三、How to build branch & merge?

trunk存放当前最新版本的源码，并作为主干分支、不允许checkout当前目录的代码直接做修改(SCM除外)

branches创建一份对应trunk代码的第一个分支（例如：crm_rel_v1.0 / zoharo_rel_v2.8）,研发人员checkout当前目录的代码做开发、commit 、update

tags中存档对应的每一个发布版本的基线（或者叫做镜像）

注意：branches / tags 中的代码均是trunk的镜像，并不是copy的模式。

Merge步骤(将branches中的代码合并到trunk中)

1. SCM(系统配置管理员)本地应有两份代码(branches/crm_rel_v2.8、trunk/crm_v2.8)
2. trunk/crm_v2.8(svn update); branches/crm_rel_v2.8 (update, commit)
3. branches/crm_rel_v2.8 --> 右键–> SVN --> Merge,如下图：
   

好了，管理员(Team leader)就可以从master中打包至测试服务器，使用真的很简单，但是很多团队却忽略了流程、标准，宁愿通宵来解决冲突、来还原版本、寻找记忆中那份没有bug的代码。

工作随笔，有不妥之处，恳请指出，以免误人子弟。

转载于:https://my.oschina.net/u/2278724/blog/1162600