单独使用 SVN 还是在小型工作组中使用 SVN - 工作流程方法?

发布于 2024-09-04 07:15:17 字数 362 浏览 4 评论 0原文

我花了几个月的时间开发 Web 应用程序,我们已经接近生产阶段。很快就需要将该项目的开发团队扩大到 1-3 人。

我没有太多使用 SVN 的经验,但它显然是大部分大公司的选择,所以我猜测 SVN 的优点毫无疑问超过了在提交/签入/检查上花费的时间 。

SVN 的工作流程似乎变得有点复杂,尽管我已经阅读了 O'Reilly Media 的《Version Control with Subversion》,而且我还不确定使用 SVN 是否太过分了 单独开发或在小型(1-3 人)工作组中开发时,除了备份之外还有什么原因吗?

你是怎么做到的?当您单独工作或在小型工作组中工作时,版本控制的工作流程是什么?

谢谢!

I have spent some months working on a web application and we're come close to production stage. It's soon time to expand the development group with 1-3 people on this project.

I have not too much experience on working with SVN, but It's obviously the choice for a big part of the larger companies out there, so I am guessing that the pros of SVN without a doubt outweights the time spent on commit/check ins / check outs etc.

The workflow seems to become a bit more complicated with SVN, and even though I have read Version Control with Subversion by O'Reilly Media and I am not sure yet if it's overkill to use SVN for any reasons besides backup when developing alone or in a small (1-3 people) workgroup?

How do you do it? What's your workflow with version control while working alone or in small workgroups?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

小耗子 2024-09-11 07:15:17

不,这并不过分。版本控制对于编程来说至关重要,无论是单独进行、在小团队中还是在大团队中。它消除了对进行“错误”更改的恐惧,因为您随时可以返回到之前的修订版本。它会记住为什么要通过提交消息进行更改。它知道一起改变了什么。还有更多

No, it's not overkill. Version control is vital for programming, regardless if it's alone, in a small or in a big team. It removes fear of doing a "wrong" change, as you can always go back to previous revision. It remembers why a change was done with commit messages. It knows what was changed together. And many more

假情假意假温柔 2024-09-11 07:15:17

与任何 SCM 一样,它的用途绝对不仅仅是备份。

  1. 您可以标记特定版本,这样您就可以在构成版本的所有代码中识别一个点。
  2. 您可以管理不同同步版本的分支,例如,如果您需要在开发解决方案的新版本时管理某个版本的错误修复。
  3. 您可以管理多个开发人员并使用 SVN 的合并功能来处理并发更改,这样您的开发人员就不会互相干扰并覆盖或删除彼此的更改。

没有SCM我不会自己开发,更不用说和其他开发者一起开发了。它是您工具箱中的核心工具,值得尽早使用。

我的工作流程是什么?这取决于团队和所使用的 SCM。

  1. 如果 SCM 很好地支持它(例如 Git),我将为每个错误/功能创建一个分支。 SVN 不太擅长分支,因此这可能不适用。
  2. 定期签入/合并。如果您不经常这样做,代码库将与您的工作代码库产生分歧,并且后续合并将变得更加困难。此外,您希望您的团队成员能够了解您正在做的事情。
  3. 我的持续集成流程(例如,我使用 TeamCity/Cruisecontrol/Hudosn 等持续构建引擎)将构建/测试,并可选择在成功的构建/测试周期上标记发布。
  4. 我将为最终版本创建一个分支,并将在发布后进行维护。

Like any SCM, it's definitely for more than backup.

  1. You can tag particular releases, so you can identify a point across all of your code that makes up a release.
  2. You can manage branches for different simultaneous releases e.g. if you need to manage bug fixes for a release whilst developing a new version of your solution.
  3. You can manage multiple developers and use SVN's merge capability to handle concurrent changes, such that your developers don't tread on each others toes and overwrite or erase each others' changes.

I don't develop on my own without an SCM, let alone together with other developers. It's a core tool in your toolbox and worth getting au fait with sooner than later.

What's my workflow ? It depends on the team and the SCM being used.

  1. If the SCM supports it well (e.g. Git), I'll create a branch per bug/feature. SVN is not so hot at branching, so this may not apply.
  2. I check in/merge regularly. If you don't do this often, the codebase will diverge from your working codebase, and a subsequent merge will become more difficult. Additionally, you want your team members to have visibility of what you're doing.
  3. My continuous integration process (e.g. I use a continuous build engine such as TeamCity/Cruisecontrol/Hudosn) will build/test and optionally tag a release upon a successful build/test cycle.
  4. I'll create a branch for a final release, and will work off this for maintenance following release.
如此安好 2024-09-11 07:15:17

布莱恩的回答没什么可补充的。作为替代方案,您可能想看看分布式源代码控制系统 (DSCM),例如 Mercurial、Git 或 Bazaar。恕我直言,它们非常适合小型开发人员团体,非常易于设置,但仍然能够扩展到大型项目。

由 Joel Spolsky 撰写的有关 Mercurial 的优秀入门教程可以在 http://hginit.com/ 中找到。

存储库布局
(来源:hginit.com

There's not much to add to Brian's answer. As an alternative you might want to take a look at distributed source control systems (DSCM) like Mercurial, Git or Bazaar. IMHO they are a perfect match for small developer groups, very easy to setup but nevertheless manage to scale to big projects.

A good introductory tutorial about Mercurial, written by Joel Spolsky, can be found at http://hginit.com/.

repository layout
(source: hginit.com)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文