SVN和部署工作流程
尽量保持简单，但由于几乎没有版本控制经验，以下是我为已经上线的 facebook 应用程序提出的版本和部署工作流程：
开发：
从主干分支
签出并设置开发环境（自动创建数据库、netbeans 项目、facebook 应用程序、配置文件）；
登台（与开发分支相同）：
运行测试（手动）；
如果可以 - svn 提交并将开发/暂存分支与主干合并
提交后挂钩，用于将项目部署到实时服务器并更新生产数据库如果需要。
同步不同的开发分支 - 如果一个开发分支升级到生产，请将其与仍在开发中的其他分支合并。
这个工作流程有什么明显的错误吗？或者关于如何改进它的任何建议。
PS：我是目前唯一的开发人员。
Trying to keep it simple, but with almost no experience in version control, here is what I came up with for version and deployment workflow for a facebook application that is already live:
Development:
branch from trunk
checkout and setup dev enviroment (automatically create database, netbeans project, facebook app, config file);
Staging (same as development branch):
run tests (manually);
if ok - svn commit and merge development/staging branch with trunk
Post-commit hook to deploy project to live server and update production database if needed.
Synchronize different development branches - if one development branch graduated to production, merge it with the other branch(es) still in development.
Are there any blaring mistakes with this workflow? Or any suggestions on how to improve it.
PS: I'm the only developer for now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来有点复杂。
为什么需要分支来进行暂存？如果您使用的是开发人员分支类型的工作流程，一旦您合并回主干，这就是您所部署的内容。
特别是因为您是目前唯一的开发人员，这听起来像是 Subversion 的过度分支和合并。我会尽力让自己的生活变得更简单，并尝试遵循 常见的分支模式。
It sounds a little complicated.
Why do you need branches for staging? If you are using a developer-branch type of workflow, as soon as you merge back to trunk, this can be what you deploy.
Especially since you are the only developer for now, this sounds like excessive branching and merging for Subversion. I would try to make life simpler for yourself, and try to keep to one of the common branching patterns.
对于一名开发人员来说这是不必要的，只需在临时分支上进行开发并在准备好后合并到主干中即可。
功能分支（您建议的工作流程）- 在需要并行开发项目/版本的大型代码库上运行良好。
发布分支 - 非常适合小型代码库，其中项目/发布遵循迭代开发周期。
For one developer it's unnecessary, just develop on your staging branch and merge into trunk when ready.
Feature branches (your proposed workflow) - work well on large code bases where projects/releases need to be developed in parallel.
Release branches - work well for small code bases where projects/releases follow an iterative development cycle.