The Guideline for Source Code Version Control

---

Git

---

• 代码所在位置：

分支	说明
master	正式分支，用于发布正式环境
developing	开发分支，用于发布开发环境
staging	测试分支，用于发布到测试环境

• 一些基本原则：
  • 开发的代码位置：
    • 所有开发，包括 bug 的修复，都尽量在 developing 上开发，当有需要时，才拉出所需的开发分支（多人协同开发，一般不需要建立个人用的开发分支）。
    • 当且仅当紧急情况下，Bug 的修改，可以直接在 staging 分支上进行。但之后必须及时 merge 回 devleoping 。
  • 某些特殊修改是只在 staging 分支上做的，不一定 merge 回 trunk，这时需要经上级许可，提交时详细记录缘由，并周知项目组成员。
    • 当从 developing 往 staging 分支上 merge 时，不一定是所有的代码都 merge 过去，可以根据发布需要将某些功能/修改，放到下一次发布。
    • 比如，alpha 4.1 上加了个功能 A，发布时决定此功能 A 要到 alpha 4.2 才发，就可以只把这次的其他修改 merge 到 staging 分支，发布 alpha 4.1 后，再将功能 A 在developing上的修改 merge 到 staging 分支，作为 alpha4.2 的发布准备。
    • 保证 developing 代码的完整性，否则当需要新分支时，就会有代码遗漏。
  • 代码提交：
    • 任何一次 commit，都必须记录有意义的 log message。
    • 每一个独立的小功能（或某个功能的阶段性）的修改完毕，就 commit
    • 不要一次 commit 多个功能。
    • 每天下班前，要commit代码，如果此功能未全部完成，必须在 log 中注明
  • Log message 必须清晰明确:

目录	说明
平时的功能添加/修改	一两句话写明本次commit代码的主要功能，比如 "add new banner of gadget in right part of page" 或 "update related keyword, using yahoo API directly from gate, not through client.intf.qiwo.mobi"
bug修改	"bug fix(#123) : only display tag within 10 characters"
merge	"* Merge r1234:5678 from trunk/portal/app to release/porta-beta-2.x/app : for beta 2.1, new design, and add ..."
Branch	"* Create branchname, from trunk/portal/app r1234, for release of portal beta-2.x"
Tag	"* Create tagname, from branches/release/portal-beta-2.x r1234, for release of portal beta-2.1"

• Tag 命名规范
  • V-主功能.正式环境发布次数.测试环境发布次数.开发环境发布次数，eg：

版本号	分支	说明
V-1.0.0.1	developing	开发环境第一次发布，第四位加1
V-1.0.0.2	developing	开发环境第二次发布，第四位加1
V-1.0.1.0	staging	测试环境第一次发布，第三位加一，第四位清0
V-1.0.1.1	developing	1.0.1后的开发环境第一次发布，第四位加1
V-1.0.2.0	staging	测试环境第二次发布，第三位加1，第四位清0
V-1.1.0.0	master	正式环境第一次发布，第二位加1，第三、四位清0
V-2.0.0.1	developing	系统主功能更新，第一次开发环境发布，第一位加1

发布流程相关代码管理

---

1. 制定 Milestone

   • 命名："项目名 版本号"，如 "Beta 2.1"
   • 确定时间，以及主要功能（目标）

2. Issue

   • 相关开发的功能需求、bug修改，都可以通过 issue 的形式提交
     • 但是，对于一些大的功能，由需求说明书制定，不一定要入到issue中
     • 后期小功能的增加/修改，以及bug修改，都入issue
   • issue 应清楚而简洁，并尽可能的附加图片说明
   • issue 如果可以有对应负责人员，及时assign
   • 中间有情况的变化，也都及时在issue中写明，比如发现了新的难点、需要design的协助、或者由于什么原因要delay到下一个版本
   • issue 修改、自测完毕后，及时close，并写明 大概的修改点（比如什么原因导致的bug）、在什么版本修改的（比如"fix in r1234 : ... "）

3. 开发/测试

   • 一般开发人员用 developing 代码，并自己搭建环境自我 debug
   • 开发一定阶段后，developing 到 staging 分支，并部署到测试环境，由测试人员或其他人员一起测试（尽量保证测试环境与正式环境的一致性）；

4. 发布前的确认

   • 发布前，需要对issue进行review，（进入测试期也需要定期review），确定是否都正确完成，或者此issue需要Delay到下一个Milestone；
   • 发布前，跟据bug的情况来决定是否能按时发布此版本；或者需要Delay发布，或者是按时发布但某些功能Delay到下一版本

5. 发布

   • 修改 CHANGES 文件，写明：
     • 此次发布的版本号码
     • 发布时间，从哪个分支发布的
     • 对应的 tag
     • 此版本主要的功能点
     • 及时打 tag
     • 关闭 Milestone

6. 其他注意事项

• 部署/升级，必须经过测试，写明简单的步骤文档，交由部署人员；尤其是测试这一环节，经常是容易遗漏的