本项目分支管理说明

版本控制分支策略介绍

Git工作流介绍

还不知晓版本控制的队友请在百度上查阅下相关资料.

常见的版本控制分支策略有三种：不稳定主干策略、稳定主干策略、敏捷发布策略。

我们项目采用 敏捷发布策略 ,这也是github上大部分团队所采用的方式,如orchard.

即在master主干上开一个发布分支, 假设为 1.0

然后1.0上需要开发20个功能,分别安排给20个开发人员,则每人从1.0分支再创建一个Feature-x(1,2,3....) 分支, 开发人员完成功能后,从 feature分支合并到1.0发布分支上,如没问题,再从1.0分支合并到master主干. 这样可以继续开始2.0的开发任务(1.0合并后,从master创建2.0的分支,之后一样每人一个分支)

hotfix (热修复)

如果在开发2.0的时候, 1.0的用户报了各种bug怎么办? 那么从之前的1.0分支再开一个hotfix-xxx的分支修改(可以开多个或者 多个开发人员),修复后直接将hotfix-xx合并到1.0,然后1.0合并到master,此时2.0只需要从master拉取下变更就ok了.

合并流程为:

开发人员自己分支(issue-xxx,feature-xxx,...) -
>
 发布分支(1.x.x)  -
>
 master(稳定主干)

hotfix-xxx -
>
 发布分支(1.x.x)  -
>
 master(稳定主干) -
>
 发布分支(2.x.x)

禁止开发人员直接推送到master分支

每个开发人员拥有自己的分支,一般用开发的功能标识分支名

为什么要创建版本分支 ?

  1. 因为我们的产品走向可能多样化
  2. 将来我们在不同时间,销售给客户肯定是不同的版本,我们无法保证所有客户的版本都是一致的最新版
  3. 不同的客户有不同的定制需求或者特定分支的bug,我们需要基于客户的版本来添加需求
  4. 有些公共的(bug/需求)我们可以合并到master, 有些定制的(bug/需求)仅仅是合并到客户的分支上.

科学的版本管理相比项目多份拷贝更能有效的降低维护成本!

创建分支

在版本库目录任意空白处右击,ToxxxGit ->创建分支->填写分支名称(feature-xxx)->勾选"切换到新分支",基于分支"1.0",点击确定! 这样你就在你的本地库创建分支了,但是这个分支目前还没有在远程,你需要做完功能后,再推送到远程

results matching ""

    No results matching ""