源代码 – 夏清然的日志 https://www.qingran.net Xia Qingran Geek Blog Sun, 07 Aug 2016 09:50:33 +0000 en-US hourly 1 https://wordpress.org/?v=4.6.1 112893047 版本控制再思考 https://www.qingran.net/2010/11/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e5%86%8d%e6%80%9d%e8%80%83/ https://www.qingran.net/2010/11/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e5%86%8d%e6%80%9d%e8%80%83/#comments Mon, 15 Nov 2010 17:37:15 +0000 https://www.qingran.net/?p=711 最近必须解决Version Control的问题了,目前使用的svn,并采用主干活跃,分支稳定的开发策略(平时的修改都在trunk进行,主干版本发布后需要修改bug才创建分支,并在分支工作,完成后merge主干),目前发现和想到的问题有以下几点:

  1. 版本库过大导致检出代码太慢(3个月过去有7000+版本,检出一次50GB);
  2. 平时工作代码的提交都在主干进行,所以主干必须能够编译,由此引出以下问题:
    • 复杂的模块儿完成时间较久,成员很久都不提交,并且提交后这段时间没有自己的修改历史日志;
    • 成员机器的硬盘在这个长时间有可能挂掉,导致工作成果丢失的风险;
  3. 成员之间交换工作成果通过svn在主干进行,违背了主干 必须能编译,并导致大量的垃圾提交。

针对以上问题目前想到的解决方法:

  1. 改用分布式版本控制工具,Mercurial和GIT,准备分别试一下;
  2. 充分利用分布式管理工具创建分支容易,速度快的特点:
    • 每个人都创建属于自己的分支,平时的工作都在分支上进行,并定期(阶段成果完成后)向主干合并
    • 自己的修改每步都可以commit到本地,每天push一次
  3. 分离美术和程序的svn目录:美术的svn目录定期干掉头1000版本。

做到以上几点后,所有提出的几点问题都应该迎刃而解。这样每个人接到工作任务后的操作顺序是以下几步:

  1. 创建属于自己的分支,可以按季度创建;
  2. 平时的工作都在此分支上进行,同时自己的每步重大修改都commit;
  3. 2天或3天视工作进度和其他人对你工作部分代码的需求而push到远程库;或者在放假前需要对代码做备份防止硬盘挂掉,也push分支工作成果到远程库;
  4. 任务完成后,测试通过后,从分支merge到主干;
  5. 新季度开始,回到操作1。

完成,临睡觉前粗糙的想了一下,应该还有很多不足之处,希望看见的兄弟多指正。

]]>
https://www.qingran.net/2010/11/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6%e5%86%8d%e6%80%9d%e8%80%83/feed/ 2 711