寻找支持标准开发和客户特定开发的版本控制系统 [英] Looking for a version control system that supports standard development and customer specific development

问题描述

在我们公司，我们构建了一个数据集成工具，并已将其出售给多个客户.大多数客户都有不同的要求.我们通过使用基于继承的自制机制实现了这些客户特定的扩展(因此每个安装都知道要加载哪些类，不加载哪些类).但是所有这些客户特定的代码仍然与标准代码在同一个代码库中.

At our company we've built a data integration tool that we have sold to several customers. Most of the customers have distinct requirements. We implemented these customer-specific extensions by using a self-made mechanism based on inheritance (so every installation knows which classes to load and which not). But all this customer-specific code is still in the same codebase as the standard code.

现在，由于多种原因(代码库变得丑陋和庞大、需求冲突等)，这不再可能了.

Now, this is no longer possible for several reasons (codebase getting ugly and large, clashing requirements, etc.)

出于这个原因，我们决定分离代码库:一个用于标准产品，另一个用于特定客户的代码库.

For this reason we have decided to separate the codebases: one for the standard product, and several customer-specific codebases.

我现在正在尝试寻找支持这种方法的版本控制系统.这是我的愿望清单:

I am now trying to find a version control system that supports this approach. Here's my wishlist:

• 支持不同版本的多个标准"代码库
  • 1.0 版本
  • 1.1 版本
  • 2.0 测试版/开发

  由于我们的团队仍然很小(约 4 名程序员)，因此开发人员自己也应该很容易处理.

  As our team is still very small (~4 programmers), it should also be easy to handle by the developers themselves.

  顺便说一句，我们的软件是使用 Spring 和 STS(因此，Eclipse 插件也很棒).

  Btw, our software is built using Spring with STS (so, an Eclipse plugin would be great too).

  到目前为止，我研究过的所有 VCS 似乎都以构建一个软件为目标——而不是几个.我希望得到一些建议或最佳实践方法.

  All VCS that I have researched so far seem to have that target of building one piece of software - not several. I am hoping for some suggestions or best-practice approches.

  推荐答案

  简单

  只需获取 git，执行拉取请求流程并利用一些 GUI，即可支持此工作流程.

  Simply

  Simply get git, go for pull request process and take advantage of some GUI, supporting this workflow.

  澄清一下，您面临的情况是:标准"开发有多个版本，它们可能独立存在以进行维护，您可能需要从新版本中获取一些修复以合并到旧版本中，您需要一种方法解决修补程序.

  To clarify, what is the situation you are facing: "standard" development comes in versions, they might live independent for maintenance, you may need to get some fixes from new versions to be incorporated in older releases, you need a way to solve hotfixes.

  所有这些问题都可以通过 git、hg 或其他分布式版本控制系统很好地解决.我已经开始使用 hg，但后来发现，git 使用得更频繁，并且在标准安装中提供了所有需要的东西(某些 hg 功能不是这种情况).

  All these things are well solved by distributed version control systems like git, hg or others. I have started with hg, but later found, git is used more often and in standard installation offers all what is need (what is not a case for some hg features).

  关于定制开发——事实上，它们在概念上与标准版本没有太大区别——你只需要对你的程序进行另一次修改，以唯一名称标识，这最终将表示，这些是定制的东西.

  Regarding custom development - in fact, they do not differ conceptually much from standard versions - you just need another modification of your program being identified under unique name, which will eventually denote, these are custom things.

  现在如何针对不同版本和定制开发处理不同的泳道"?

  Now how to approach different "swim-lines" for different versions and custom developments?

  明显的答案是分支".有很多关于各种分支模型的教程，它们应该可以解决您的问题.

  Obvious answer is "branching". There is a lot of tutorials on various branching models and they shall be solving your problem.

  然而，分支也不是微不足道的，你可能会发现关于哪种风格最好的长期争论.

  However, branching is not trivial either and you may find long disputes on what style is the best one.

  幸运的是，还有更简单的解决方案 - Pieter Hintjens 文章 http://hintjens.com/blog:24 关于被认为有害的分支"提供了更简单的模型，使用主题存储库和拉取请求过程.这是 GitHub 和 BitBucket 上管理的项目数量，我发现这确实是风险最小的最有效的解决方案.

  Fortunately, there are even simpler solutions - Pieter Hintjens article http://hintjens.com/blog:24 about "Branching considered harmful" provides simpler model, using topical repositories and pull request process. This is how many projects on GitHub and BitBucket are managed and I found this really the most effective solution with minimal risks.

  对于pull request的工作过程，有一些GUI是很方便的，它支持相关的通信——除了GitHub和BitBucket之外，市场上也有解决方案(包括一些开源的解决方案).

  For pull request working process, it is handy to have some GUI, which supports related communication - and apart form GitHub and BitBucket, there are solutions on the market (incl. some open source solutions).

  为长期运行做好准备——从 Pieter Hintjens 的链接文章开始可能会让你的运行时间更短，下一步可能是在 BitBucket 上玩一个项目，然后设计最终"系统(无论如何都会在时间，但 git repos 非常适合与更改保持一致).

  Prepare yourself for long run - starting with linked article by Pieter Hintjens may make your run a bit shorter, next step could be playing with a project on BitBucket or so, then design "the final" system (which will anyway evolve during time, but git repos are well suited to keep with the changes).

  这篇关于寻找支持标准开发和客户特定开发的版本控制系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！