简易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-dev，dev，Reporter；
  • 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-dev和dev；
    • 一般来说，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