git 使用规范

分支命名及使用说明

 

master分支

master 为主分支，线上环境分支。确保master分支的稳定性； master 分支只从release、hotfix两条分支合并代码；

master 分支是受保护的，只能固定的PM能做合并

 

release分支

 

release 为预发布分支，测试完成后从maser分支创建一条release分支，合并已确定需要上线的功能分支（如果确保功能可以全部上线，那就从develop分支创建一条release分支即可）；

release 分支是指以release/开头的特性分支，并不是指某一条分支。命名规则为：release/0.1.0、release/0.2.0； 

release 发布至准生产环境，测试人员进入准生产环境进行上线前回归，产品进行验证； 

release 发布到准生产后，如果有问题直接在release分支进行修改，重新发布准生产；

release 验收成功后合并至master分支进行生产发布；

 

develop分支

develop 为最新的开发分支，最新已提测功能，修复功能Bug后的开发代码； 

develop 分支是不可以做编码工作；

develop 分支也是受保护的，每次合并应当执行代码审查，固定的PM做合并；

develop 分支合并完成后即发布到测试环境进行测试；

develop 分支除了可以往release分支合并，禁止往其他分支进行合并； 

 

feature分支

 

feature 分支一定要从master分支拉取，并且如果开发中有其他功能上线，需要及时同步master分支代码； 

feature 分支是指以feature/开头的特性分支，并不是指某一条分支。命名规则为：feature/user_model、feature/order_model； 

feature 特性分支下应该固定有一条feature/common_model分支，用于开发正在开发中需要用到的公共功能开发，他也不允许合并其他分支；

feature 分支在开发过程中可以允许合并feature/common_model分支，但不允许合并其他的功能分支；

   

hotfix分支

 

hotfix 分支为线紧急Bug修复分支。他直接从master分支拉取；

hotfix 分支是指以hotfix/开头的特性分支，并不是指某一条分支。命名规则为：hotfix/1.01_bug、feature/1.20_bug；

hotfix 分支修复完Bug后直接发布至准生产环境，产品，测试快速测试，测试通过则合并回master分支；

hotfix 分支上线完成需要通知其他feature开发分支拉取最新的master代码；

   

应用场景

 

场景一：新功能开发

 

某天产品老大跑来跟你说，我们的平台要加个学生入学和学生退学的功能。这时候我们该怎么做呢？

   

第一步：先从master拉取新分支，两条新功能分支；

 

$: git checkout -b feature/enterSchool_model  //入学功能分支
$: git checkout -b feature/outSchool_model    //退学功能分支

   

第二步：第一天各自开发功能，下班时提交代码至远程

 

$: git checkout  enterSchool_model
$: git add .   
$: git commit -m '第一天A同学的开发成果'
$: git push     //推送到远程　

 

第三步：第二天来上班时，发现平台昨晚有上线新功能了，先拉取master代码到自己的分支再开始开发

 

//拉取master代码至自己的开发分支
$: git checkout master   
$: git pull origin master 
$: git checkout enterSchool_model
$: git merage master//继续第二天的开发
$: git add .   
$: git commit -m '第二天A同学的开发成果'
$: git push //推送到远程

    

第四步：就这样第三步重复直到功能开发完成，开发完成后向develop发起合并请求；

   

第五步：PM进行代码审核，（如果不通过，开发人员继续在自己的功能分支修改代码，完成后，重新回到第四步）通过后发布至测试环境；

   

第六步：测试人员进行测试，（如果有Bug，开发人在自己功能分支修改Bug，完成后，重新执行第四步）直至测试通过；

   

第七步：从develop分支创建release分支，进行准生产环境验收测试。（如果只能上线部分功能则从master分支创建release分支，合并需要上线的功能分支）；

   

第八步：验收有Bug,开发人员直接在release分支进行紧急修复，并直接发布至准生产环境；

   

第九步：验收通过release分支合并至master，并发布至生产环境；

   

第十步：通知其他还在开发的人员直接同步master分支代码；

   

场景二：公共功能开发

 

还是同上面的故事，前端团队在拿到需求进行分工时。发现两个人的页面都有一个学生信息的弹窗，还有都需要一个时间格式化方法。这时候俩人一合计打算把这个学生信息弹窗做成一个业务公共组件，格式化时间抽出来做公共方法。那这时候我们应该怎么做呢？

   

第一步：一样先拉两条功能模块分支，然后再创建一条叫feature/common_model的公共功能分支；

 

$: git checkout -b feature/enterSchool_model  //入学功能分支
$: git checkout -b feature/outSchool_model    //退学功能分支
$: git checkout -b feature/common_model    //公共功能分支

   

第二步：俩人中选一个人在公共功能分支上开始开发公共功能，另一人还是在自己的功能分支上开发与公共功能不相关的业务；

   

第三步：公共功能开发完成，则通知其他开发人员直接合并feature/common_mode分支代码；

   

第四步：业务开发人员合并代码开始整合与公共功能部分，如果有问题则通知组件开发人员修改，重新回到第三步；

   

第五步：业务开发人员继续开发，直到功能开发完成。向develop分支发起合并请求，并提测。剩下步骤参考场景一；

   

(公共功能开发也可以第三人来开发)

   

场景三：线上Bug修复

 

我们上面的功能完成后，突然有一天某位同事发现了一个Bug，入学的时候少存了一个重要信息，需要紧急修复。这时候我们该怎么操作呢？

   

第一步：从master拉hotfix分支

 

(master)$: git checkout -b hotfix;

     

第二步：修改Bug并提交，

$: git add .
$: git commit -m '修复的bug描述XXXX';
$: git push 

   

第三步：直接把hotfix分支发布至准生产环境。测试、产品进行测试、验收，（验收不通过重新执行第二步，直至验收、测试完成）；

   

第四步：验收通过合并回master分支，并发布至生产；

(master) $: git merage hotfix/xx_bug

 

第五步：生产上线成功，通知其他正在开发的人员进行代码同步。各feature分支直接同步master代码即可；