日常工作中,80%的SVN操作应遵从以下固定的步骤::
我们鼓励全体开发人员遵循以下SVN操作: 0. 工作之前,恰当的检出属于自己的代码(co) 1. 检入之前,必须重新同步本地代码(update) 2. 检入之前,后检入的人有责任解决合并冲突(ci) 3. 若无合适的理由(例:改善可靠性/可读性等)不得随意回退别人做过的修改 |
|
恰当的检出属于自己的代码::
- 意味着:
- 在一切开始之前请询问管理员,确定我们的SVN服务访问地址以及自己所属的工作区域 -- SVN项目目录
然后要开展协同开发,首先是建立本地副本,即,checkout——检出代码
标准命令:
svn co svn://cvs.woodpecker.org.cn/woodpecker/zqlib/trunk ^ ^ ^ ^ ^ ^ ^ | | | | | | +- 主线目录 | | | | | +- 项目目录 | | | | +- 仓库名 | | | +- SVN服务域名 | | +- 访问协议,SVN支持从HTTP到file 等多种访问模式! | +- checkout 检出代码 +-- svn 命令和cvs类似是我们日常工作的基础工具命令
- 意味着:
修改文件之前要update。这意味着修改时的版本尽可能新,一旦发生冲突,解决它的工作量会比较小。
标准命令:
svn up
在开发过程中应经常执行更新操作,以免与别人的工作发生冲突。
修改完成并调试成功后,及时提交——commit
标准命令:
svn ci -m "注释文本"
调试成功后——意味着:
- SVN仓库中应该永远只存可用的代码,未调试成功的实验性代码,不应该检入!
及时——意味着:
- 本地代码与代码库中的代码差异越小,别人合并的难度也就越小(他们有比较大的概率能够拿到新的版本)
- 同一功能涉及的所有代码一次commit。不应该将涉及同一功能修改的代码分开commit,因为这会给日后的追踪带来麻烦。
- 将不同的功能单元修改分开commit。
- 一方面,这样做能够尽早地commit,减少别人合并的难度;
- 另一方面,由于cvs提供了回退到先前版本的能力,一旦由于某项功能修改造成问题,也很容易将那次修改的内容,而不是整个修改回退到正常的代码。
提交时 写清 commit log(提交日志)
写清 -- 记录为什么进行代码的修改,以及进行了什么样的修改,清楚的commit log能够帮助其他开发者在不仔细阅读代码的情况下了解修改的内容,从而极大地提高开发效率;另一方面,这些日志对于开发者自己,以及整个开发团队,都是非常宝贵的财富。
具体的参考: 理性CommitLog约定