一、开发周期和sprint概述

1.1 sprint周期

按照固定周期（一个sprint，通常是1周或者2周）发布新版本。

目前规划：每一到二周一个sprint，最长不超过1个月

全部code提交、合并至release，部署到测试环境并开始集成测试

1.2 每个周期开始（或者上个周期快结束）时，大致确定下来下一srpint周期要完成的任务。通常有一些新feature，也有一些旧bug。

1. feature的分解：一个大的feature，通常不会在一个sprint里完成。一个sprint里，也不会只做一个新feature。为此，需要各feature小组把该feature分解成若干阶段，方便在各个sprint分别提交。
2. 各bug均可在自己的分支里工作，快速修复并提交。不用多个bug挤在一个分支里。
3. bug的选取：通常按照优先级。优先级同样的，优先修复新近发现的。（注意，这里的bug指的是backlog里已有的、某种程度上不是火烧眉毛的那种bug，可以不太紧张地排期来修。还有一种bug是在线上系统发现的、火烧眉毛的、必须立即修复并上线的，通常叫hotfix。）

1.3 每天早上都要同步（更新）一下code，把本feature小组别人已经提交的code同步下来，及早发现和解决冲突。

1.4 一个sprint里，每个开发人员都要对该spirnt的deadline心里有数。在临近deadline时，注意提交代码的质量。

1.5 每个feature小组，每次push到自己的远程分支，都应该对此次提交的代码的质量有足够信心（也就是说，经过了足够的自测）。

1.6 临近sprint deadline时，各组协调一下，把各自远程分支按一定顺序依次合并到release分支。后合并的，要先同步一下code，预防冲突。

1.7 所有feature分支、bug分支都合并到release分支后，部署到SIT环境上，进行一定程度的集成测试，并修复发现的bug。

1.8 若测试量大：测试人员测试若干天，开发人员同时开发下一sprint的任务。

1.9 上线。

1.10 线上发现问题：回滚 vs. hotfix.

二、具体git操作概述

gitlab上长期保留两个branch：master、release。并临时保留若干 feature-{jira编号}-{date}，例如：feature-SEH-2-20211231，分支，用于新功能开发。

每次有新功能要开发，要从release拉出新分支（命名为 feature-{jira编号}-{date}）。该功能开发小组的各成员都在 feature-{jira编号}-{date} 分支上工作，在本地feature-{jira编号}-{date}分支上commit上并push到远程feature-{jira编号}-{date}分支上。

注意：这里的jira编号为story或feature编号，当项目上线之后，分支会保留留一段时间（一般一周左右，最长不不超过1个月），直至最终删除

2.1 新功能开发完成后，从远程feature-{jira编号}-{date}分支上合并到远程release分支上。

大致工作流程如下：

1. gitlab上长期保留两个分支：master、release。

release分支是定时更新的相对稳定的版本，从各feature、bugfix分支合并而来，生命周期是一个sprint。

master分支是保持永远稳定的版本，从release分支合并而来，落后release一个版本。

2. 每次有新功能要开发，要从远程release分支拉出远程新分支（命名为feature-{jira编号}-{date}），由各个feature的负责人或者主力开发人员负责，过程如下：

从远程仓库clone到本地：

git clone git@gitlab2.ciics.cn:zyf-service/zyf-service-claim.git

创建本地feature-{jira编号}-{date}分支，跟踪远程release分支：

git checkout -b feature-{jira编号}-{date} origin/release

从本地feature-{jira编号}-{date}分支push到远程，以创建远程feature-{feature_name}-{date}分支：

git push -u origin feature-{fjira编号}-{date}

注意：feature的负责人有以下职责：

负责创建feature-{jira编号}-{date}分支

开发完成后合并feature-{jira编号}-{date}分支到release分支，解决冲突

3. 其他每个小组成员也在feature-{jira编号}-{date}分支上工作：

从远程仓库clone到本地：

git clone git@gitlab2.ciics.cn:zyf-service/zyf-service-claim.git

checkout 到分支feature-{jira编号}-{date}：

git checkout feature-{feature_name}-{date}

在本地feature-{jira编号}-{date}分支上工作、开发、修改，及时提交到本地：

git add xxx.file

git commit -m "JIRA-CODE commit log"

工作过程中，经常从远程同步代码：

git remote update

git rebase origin/feature-{jira编号}-{date} //发生冲突要及时解决

把本地改动push到远程同名分支。要经常：

git remote udpate

git rebase origin/feature-{jira编号}-{date} //发生冲突要及时解决

git push origin feature-{jira编号}-{date}

4. 在适当时候，把远程feature-{{jira编号}-{date}分支合并到远程release分支。

什么是“适当时候”？如果feature较小，两三天就做完，则“feature做完时”是合适的。若feature较大，需要跨若干sprint，则“每个sprint结束时”是合适的。每个sprint是多长时间则可视具体情况而定。

这个merge过程，需要在gitlab的web页面上提交一个“Merge Request”。该请求会发出一个code review请求。

过程如下：

在我们工程页面下点击New Merge Request

选择source和target branch，填写相关内容，并提交

提交merge request，如果想从新选择分支，可以点击Change branches,请求被接受后，gitlab上自动完成merge过程，不用人工再输入命令。

release代码只有所属小组的组长有权限合交，组长在收到merge request的时候做code review,code review规范见第四章经过若干次从feature-{jira编号}-{date}分支合并到release分支及相应测试，可认为release分支稳定，可以正式对外发布，此时将release分支合并到master分支，并在master分支上打tag，如 v2.0.0等。可以同时有若干 feature 分支和或 bugfix-{jira编号}分支进行工作，流程类似。若master分支上上线后发现了bug需要紧急修复，可从master分支拉出hotfix-{jira编号}，例如hotfix-{SEH-100}，分支工作，经过测试过后合并到master分支上，每次合并到master分支，都要把修改同时提交到release分支，同时通知所有feature分支都同步这次修改：

5. 打TAG版本号管理

6. 在release分支上执行以下命令以把hotfix的修改提交到release分支上：

git remote update

git rebase origin/release

git push

各个feature分支也要合并这次修改：

git remote update

git rebase origin/release

git push

三、关于commit代码提交

正确的版本控制系统的使用方法是，一次提交只干一件事：或是完成了一个新功能，或是修改了一个Bug、或是写完了一节的内容，或是添加了一幅图片，就执行一次提交。不要在下班时才想起来要提交，那样的话版本控制系统就被降格为文件备份系统了。

如果一件事提交了多次，把多次合交为一个commit,比如修复了一个hotfix,那么应该只是针对一个commit.

git关联jira的ISSUE提交示例，提交方式如下所示：

git commit -m ISSUE_KEY comment _string

例如：

git commit -m 'SHE-2 修复空指针BUG'

注意： 这里的ISSUE_KEY是指JIRA的TASK ID 或 BUG ID