本贴最后更新于 336 天前,其中的信息可能已经时异事殊

背景

  • 目前负责小组内源码的版本管理,将目前的我们的源码管理策略做一番梳理和分享,以期共同进步。

流程

  1. 先建立主分支 master
  2. Owner 基于 master 建立开发分支 xxx-dev-v1,xxx-release-v1, 分别是第一期开发版本, 第一期发布版本。
  3. xxx-dev-v1 供开发人员拉取并开发,功能点开发完成且单元测试通过后,将开发代码提交到 xxx-dev-v1 上。
  4. 测试人员测试 xxx-dev-v1 的代码,测试通过后,由本人将 xxx-dev-v1 的代码合并到 xxx-release-v1,待发布。发布前若测试人员发现 bug, 则重复 3、4 步。
  5. 发布时,由 Owner 将 xxx-release-v1 合并到 master 分支,合并后 master 分支打 tag,如 master> git tag 20171220-v1.0,然后运行自动发布脚本进行发布。
  6. 项目是迭代开发,第一期完成后该进行第二期开发,命名方式相同,依次类推。
  7. 如果在开发 V2 的过程中,需要紧急修复 V1(线上)中的漏洞,则重复 3、4、5 步,并在最后将 master 的代码合并到 V2 上,以保证 V2 的代码最新;如评估后不紧急,可放在 V2 中开发。

注意

  1. 务必保证 master 是线上最新版本。
  2. 可改进的地方:经过一段时间的策略使用,认为目前的问题在于角色分工上不够明确,具体表现在两个问题:(1)开发人员代码开发并提交 dev 分支后,应该提起 dev 到 release 的合并请求,由 Owner 审核后通过,而不是 Owner 发起合并(2)测试人员在测试没有 bug 后应提起 release 合并到 master 的请求,而不是由 Owner 发起合并。

  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    133 引用 • 240 回帖 • 969 关注
  • 版本控制
    2 引用 • 1 回帖
  • master
    3 引用 • 17 回帖
感谢    关注    收藏    赞同    反对    举报    分享