内部应用程序的源代码控制分支方案
我习惯了源代码控制分支方案，其中为产品的每个主要版本创建分支。我可能忽略了这种模型的一些潜在好处，但我认为主要好处是它允许在带外修补版本。
对于除了最新版本之外永远不会有补丁的产品（例如网站和内部应用程序）来说，这种模型似乎过于复杂。
我正在考虑将我们的内部应用程序迁移到两个分支模型：开发 和生产。 development 分支将用于产品的下一个版本，而 product 分支将用于修补产品的当前版本。
我是否过于简单化，或者错过了版本化分支结构的其他一些好处？其他人在内部应用程序和网站中成功使用过什么？
I'm accustomed to a source control branching scheme where branches are created for each major version of a product. I may be overlooking some latent benefits of this model, but I think the main benefit is that this allows releases to be patched out-of-band.
It seems like this model is overly complicated for products that will never have patches for anything but the most recent release (such as websites and internal applications).
I'm considering moving our internal applications to a two branch model: development and production. The development branch would be for work on the next version of the product, and the production branch would be for patching the current version of the product.
Am I oversimplifying, or missing some other benefit of a versioned branching structure? What have other people used successfully for internal applications and websites?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的开发团队使用类似的策略，只是我们还使用第三个分支进行测试。我们有一个小团队，而且运作得很好，因为我们不会浪费太多时间来处理合并、工作副本和其他浪费时间的麻烦。我认为，如果我们的团队规模突然增加一倍或三倍，它的规模不会很好，但在这种情况下，我们需要担心的不仅仅是颠覆分支。
我认为修剪分支确实不会错过许多重大好处。如果您的团队很小和/或每个人都有明确定义的任务，并且不会干扰其他人的工作，那么就可以省去维护臃肿存储库的麻烦。不过，从事这方面工作的人越多，解决合并冲突的机会就越大。
My development team uses a similar strategy, except we also use a third branch for testing. We have a small team and it works very well because we don't lose much time dealing with merging, working copies, and other time-wasting hassle. I don't think it would scale well if we suddenly doubled or tripled our team size, but we would have a lot more to worry about than subversion branching in that case.
I don't think you're really not missing out on many major benefits by pruning your branches. If your team is small and/or everyone has clearly defined tasks that don't interfere with anyone else's work, then save yourself the trouble of maintaining a bloated repository. The more people you have working on it, though, the greater chance of having to sort out merge conflicts.