美文网首页管理PHP学习笔记
GitFlow学习笔记-操作流程(一)

GitFlow学习笔记-操作流程(一)

作者: 赵客缦胡缨v吴钩霜雪明 | 来源:发表于2019-01-30 12:02 被阅读87次

    GitFlow工作流操作流程

    1. 主要分支介绍

    image

    1.1 master分支

    主分支,产品的功能全部实现后,最终在master分支对外发布。

    1.2 develop分支

    开发分支,基于master分支克隆,产品的编码工作在此分支进行。

    1.3 release分支

    测试分支,基于delevop分支克隆,产品编码工作完成后,发布到本分支测试,测试过程中发现的小bug直接在本分支进行修复,修复完成后合并到develop分支。本分支属于临时分支,目的实现后可删除分支。

    1.4 bugfix分支

    Bug修复分支,基于master分支或发布的里程碑Tag克隆,主要用于修复对外发布的分支,收到客户的Bug反馈后,在此分支进行修复,修复完毕后分别合并到develop分支和master分支。本分支属于临时分支,目的实现后可删除分支。

    1.5 feature分支

    功能特征分支,基于develop分支克隆,主要用于多人协助开发场景或探索性功能验证场景,功能开发完毕后合并到develop分支。feature分支可创建多个,属于临时分支,目的实现后可删除分支。

    2. 新功能开发工作流

    2.1 切换到本地仓库工作区

    cd /home/timerhunter/workspace1
    

    2.2 从远程仓库克隆代码到本地仓库

    $git clone https://xxxx@localhost:8443/r/valve/V5-Lora.$git1
    

    2.3 基于master分支,创建develop分支

    /* 切换到master分支 */
    $git checkout master
    /* 基于master分支克隆develop分支,并在克隆完毕后直接跳转到develop分支 */
    $git checkout -b develop
    /* 推送develop分支到远程仓库 */
    $git push origin develop123456
    

    注:编码工作主要在develop分支,master分支主要用来发布稳定版本

    2.4 在本地仓库的开发流程

    完成一个功能点或者一天的工作结束时,将代码提交到本地仓库

    /* 提交修改到缓冲区 */
    $git add .
    /* 提交修改到本地仓库 */
    /* 如果是修复的BUG,应该在修改说明的最开始添加Bug#ID,多个Bug用逗号分隔,例如Bug#002,003 */
    /* 如果是完成了一个指派的任务,应该在修改说明的最开始添加Task#TaskID,例如Task#165 */
    $git commit -m "Bug#123 修改说明"
    /* 每完成一个功能点可以对代码进行打包 */
    $git tag -m "简要说明增加/修复/删除了什么功能" v0.0.0.17071812345678
    

    注:不是每一个Tag都需要提交到远程仓库,比如可以在完成一个功能点的编码工作后未编译就打一个包,仅存储于本地仓库,在编译成功&测试通过后,再打一个新的Tag包(里程碑Tag包),仅将里程碑Tag包推送到远程仓库

    2.5 推送代码到远程仓库

    当完成一个功能点或阶段工作时,将代码推送到远程仓库develop分支

    /* 执行代码拉取操作,防止代码冲突 */
    $git pull
    /* 解决代码冲突后,推送代码到远程仓库*/
    $git push origin develop1234
    

    注:禁止将未编译或编译不通过的代码提交到远程仓库,如果编码工作进行未完成可以提交到本地仓库中,等待该功能点全部实现后再将代码推送到远程仓库中。

    2.6 将代码发布到测试分支

    阶段性的开发工作已完成,启动小批量测试工作,将代码发布到测试分支release

    $git checkout develop
    $git checkout -b release
    $git push origin release123
    

    2.7 测试工程师提交Bug后修复

    • 从远程仓库拉取代码
    /* 克隆仓库 */
    $git clone https://admin@192.168.1.88:8443/r/admin/test.$git
    /* 查看远程仓库分支情况:克隆仓库时只能克隆master分支,因此需要拉取指定分支,我们使用$git branch -r查看远程分支情况 */
    $git branch -r
      origin/HEAD -> origin/master
      origin/dev
      origin/master
      origin/release
    /* 拉取测试分支 */
    $git checkout -b release origin/release12345678910
    
    • 修复流程同#2.4,#2.5;
    • 注意在$git commit时的修复说明中添加Bug#BugID关键字
    • 完成一个Bug修复或完成阶段性工作后,将代码推送到远程分支

    2.8 测试工作完成后,合并代码到develop分支

    /* 切换到develop分支 */
    $git checkout develop
    /* 执行合并操作,将release分支代码合并到develop分支 */
    $git merge release
    /* 如果合并报错,则解决冲突,冲突解决后继续再次执行合并 */12345
    

    2.9 开发工作和测试工作都完毕后,发布时将develop分支合并到主线

    $git checkout master
    $git merge develop12
    

    2.10 阶段开发完毕,打一个里程碑Tag包

    /* 创建里程碑Tag */
    $git tag -m "Task#003 v1.0.0 首版发布" v1.0.0.170718
    /* 推送里程碑Tag到远程仓库 */
    $git push origin v1.0.0.1707181234
    

    3. 发布后的产品Bug修复工作流

    3.1 获取Bug产品的软件发布版本号

    3.2 查找里程碑Tag

     /* 查询里程碑及其提交说明 */
     $git tag -n1 -l v*12
    

    3.3 基于里程碑Tag创建分支

     /* git checkout -b [创建的分支名称] [里程碑Tag名称] */
     $git checkout -b bugfix-v1.0.0.170718 v1.0.0.17071812
    

    3.4 修复代码后可以查询修改过的地方

     $git diff1
    

    3.5 修复完毕后分别合并到develop分支和master分支

    /* 合并到develop */
    $git checkout develop
    $git merge hotfix-v1.0.0.170718
    /* 提交到远程仓库develop分支 */
    $git push origin develop
    /* 合并到master:如果随下一个版本再发布,可不用合并至master分支 */
    $git checkout master
    $git merge develop
    /* 提交到远程仓库master分支 */
    $git push origin master12345678910
    

    3.6 创建新的里程碑Tag

     $git tag -m "Bug#002 修复某某Bug" v1.0.1.170719
     /* 推送到远程仓库 */
     $git push origin v1.0.1.170719123
    

    3.7 删除bugfix分支

    /* 删除本地分支-$git branch -d [本地分支名]*/
    $git branch -d bugfix-v1.0.0.170718
    /* 删除远程分支-$git push origin :[远程分支名]*/
    $git push origin :bugfix-v1.0.0.1707181234
    

    4. 日常开发过程中常用操作

    4.1 撤销操作

    4.1.1 提交后发现丢了几个文件没有提交
    /* 正常提交 */
    $git commit -m "发布v1.0"
    /* 发现丢了修改记录,重新添加 */
    $git add CHANGELOG.md
    /* 重新提交,仍以"发布v1.0的名义提交",最终只有一个提交*/
    $git commit --amend123456
    
    4.1.2 撤销上一次的提交,但是保留暂存区和当前修改不变
    /* 正常提交 */
    $git commit -m "发布v1.0"
    /* 将会撤销“发布v1.0”的提交,但是保留暂存区和当前目录中文件的修改 */
    $git reset --soft HEAD~1234
    
    4.1.3 撤销上一次的提交和暂存区修改,仅保留当前修改不变
    /* 正常提交 */
    $git commit -m "发布v1.0"
    /* 将会撤销“发布v1.0”的提交,但是保留暂存区和当前目录中文件的修改 */
    $git reset --mixed HEAD~1234
    
    4.1.4 撤销上一次的提交,并丢弃所有修改,包括暂存区和当前目录中的修改,整体回档到上上次的提交
    /* 正常提交 */
    $git commit -m "发布v1.0"
    /* 将会撤销“发布v1.0”的提交,但是保留暂存区和当前目录中文件的修改 */
    $git reset --hard HEAD~1234
    
    4.1.5 撤销暂存区和当前目录下所有文件的修改,整体回档到上一次提交

    注意:此操作非常危险,会丢失所有修改,直接整体回档到指定的版本,谨慎使用

    /* 正常提交 */
    $git commit -m "发布v1.0"
    /* 修改多个文件 */
    /* 添加到暂存区 */
    git add .
    /* 撤销暂存区和本地目录下所有文件的修改,并整体回档到上一次提交的状态 */
    $git reset --hard HEAD
    /* 可以修改HEAD为SHA-1值回档到任意版本 */
    /* 使用git log查看每次提交的SHA-1值,可以仅指定前7位 */
    $git reset --hard 745d8cd12345678910
    
    4.1.6 将文件提交到暂存区后撤回

    在对文件执行git add操作后,重新撤回

    /* 添加文件到暂存区 */
    $git add README
    /* 将文件从暂存区撤回 */
    $git reset HEAD README1234
    
    4.1.7 撤销对文件的修改

    在对文件进行修改后,发现思路不对,需要将文件恢复至原有状态

    /* 撤销对CHANGELOG.md文件的修改,请注意这是一个危险的命令,
     * 对指定文件的修改都会被取消,会还原成上次提交的样子 */
    $git checkout -- CHANGELOG.md123
    

    目前仅用到这些流程,新学有不足的地方请指出交流。

    相关文章

      网友评论

        本文标题:GitFlow学习笔记-操作流程(一)

        本文链接:https://www.haomeiwen.com/subject/bggqsqtx.html