freelogic's blog

2018-01-03-简易GIT开发流程指南

简易GIT开发流程指南

(假设您的组织在内网搭建了最新免费的gitlab平台,并用他和GIT结合来管理源代码)

第1节 GIT的SSH配置

  • 参考:https://gitlab内网ip/help/ssh/README
    • 建议配置ssh并启用,如果实在不合适,可用https替代。
  • GIT的SSH配置步骤
    • 1.安装git 官方下载
    • 2.在pc任意位置右键选着 “Git Bash here”
    • 3.输入命令 : ssh-keygen -t rsa -C xxx@xxx.com (邮箱地址)
      • 公钥私钥会生成在: C:\Users\Administrator.ssh文件夹下,用文本打开id_rsa.pub ,拷贝内容
      • 注意: 不用ssh专门工具而直接在win目录下是无法创建诸如‘.ssh’这样名字的文件夹的
    • 4.将拷贝的公钥内容拷贝到: https://gitlab内网ip/profile/keys 中保存即可
  • GIT的HTTPS使用步骤
    • 为了避免SSH的麻烦,也可以直接使用https资源,在IDE环境上下文中对https协议形式的远端git仓库操作时,OS(WIN)会跳出https账号密码输入框,输入后记录到“OS的凭据”;
    • 如果IDE环境下对https的git远端仓库使用正常,如果需要到git base的命令行操作,是一样的;
      • 先打开所在项目的目录,比如“project1”,它包含子目录“.git”;
      • 在这个目录下,鼠标右键选择“git base here”命令,会打开mingwin/cyxwin(win下模拟linux的工具)等命令行环境;
      • 此时使用git命令pull和push,会自动调用“OS的凭据”来操作远端的GIT仓库,而不是使用SSH秘钥对;

第2节 GIT精简流程描述

  • 参考1: simple-git-workflow-simple
  • 参考2: GIT用法图文版(极好)
  • 分支说明:
    • master分支:由Owner负责新建,或删除;main-dev可以更新(比如从feature分支往master分支做PR合并等);
    • feature分支dev本地开发用,多人开发一个feature,特别要注意提交和沟通,虽然本地feature分支是私人互不影响,但提交后容易merge冲突,事先要沟通好,不要让main-dev为难。
      • 注意:远端GIT仓库只有1条feature分支,需要dev把它拉到本地的某个条分支(比如叫:“pbi_u1234);
    • PR(Pull Request): 一般dev从feature分支向master分支发起PR合并请求,main-dev审批并执行,并通知相关dev等;
  • 角色定义:
    • Owner:一般是Master,或PO,或专门人员;
    • main-dev:主程序员,也是开发者,额外处理PR;
    • dev:开发人员,也是开发者;
    • Reporter:issue报告者,一般是测试人员;
  • 步骤定义:
    • STEP1:Owner建立项目和master分支;
    • STEP2:Owner添加角色main-devdevReporter
    • STEP3:Owner定义分支策略和权限;
    • STEP4:main-devpush第一个master分支的版本;
    • STEP5:devpull最新master分支;
    • STEP6:dev本地建立远端feature分支的本地开发分支(local branch)做开发(建议名称为:”pbi_u1234”以示区别);
    • STEP7:dev本地feature分支酌情用rebase来摘取master最新代码;
      • 不能用rebase来摘取远端feature分支,因为feature分支仅供main-dev单向合并到master分支(通过PR)用;
      • 如有冲突,就要解决,或通知其他main-devdev
      • 一般来说,main-dev合并了某dev交付的feature提交后,应该不会引起merge冲突;
    • STEP8:dev本地开发完或能原子完整提交,则申请PR并通知main-dev
    • STEP9:main-dev查看PR(PULL REQUEST),审批,同意,无冲突,则合并到master分支,并通知其他dev做rebase(此时dev可以删除本地工作分支”pbi_u1234”);
    • STEP10:对于dev的某个feature提交,远端feature分支应该是能正确编译打包和测试该feature的;此时Reporter可以测试该feature并提交issue;
    • STEP11:步骤7,8,9会反复做;
    • STEP12:全部feature开发完成且合并到master后,对master分支打包(也许通过GITLAB的CI工具),Reporter测试全部feature并(可能不同feature会互相影响)并提交issue;
      • 对应SIT;
    • STEP13:最后,发布前打出Release分支(从master打出来),仅供只读发布版本;
    • 其他:
      • issue:一般来说,issue人人可提,并将被owner或main-dev打标签(tag)为”req/pbi”或”bug”等;
      • hotfix分支:如果要针对某个Release的版本(分支)临时解决某个issue,解决完,可能会打一个hotfix分支临时发布,但终究是要合并到master,在下一个Release中体现;

END