源代码控制 ߝ 每个产品都需要一个单独的分支吗？
假设您有四种产品，每种产品都有自己的发布时间表。 每个产品都有 50% 的共享代码（所有产品的通用功能）和 50% 的产品特定代码。
您是否需要为每个产品建立一个单独的源代码控制分支？ 通用功能是否应该始终在四个产品分支之一中开发，然后合并到其他产品中？
典型场景：产品A下个月发布，需要核心（共享）增强1，产品B四个月后发布，需要核心（共享）增强2（需要三个月完成）。
Let’s say you have four products each with their own release schedule. Each product has 50% shared code (common functionality across all products) and 50% product specific code.
Do you need a separate source control branch for each product? Should common functionalities always be developed in one of the four product branches and merged to the other products later?
Typical Scenario: Product A is being released next month and requires core (shared) enhancement 1, product B is being released in four months and requires core (shared) enhancement 2 (which will take three months to complete).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我将共享代码保存在它自己的产品文件夹中。 然后使用 svn:externals 在其他产品之间共享代码。 处理分支和合并有点痛苦，但这比在存储库中拥有四个共享代码副本要好。 像这样的东西（对于发布分支和标记版本，将主干替换为 /branches/RB-1.0.0 或 /tags/REL-1.0.0 ）：
UPDATE0：请注意 /product_a/tags/REL- 1.0.0 可能使用 /core/tags/REL-1.0.0 而 /product_b/tags/REL-1.0.0 可能使用 /core/tags/REL-1.1.0
I keep shared code in it's own product folder. Then use svn:externals to share the code amongst the other products. It's slightly painful to handle branching and merging, but it's better than having four copies of the shared code in the repository. Something like this (replace trunk with /branches/RB-1.0.0 or /tags/REL-1.0.0 for release branches and tagged releases):
UPDATE0: Note that /product_a/tags/REL-1.0.0 might use /core/tags/REL-1.0.0 while /product_b/tags/REL-1.0.0 might use /core/tags/REL-1.1.0
通用功能可以在单独的平台分支中开发，每个产品都有自己的分支用于特定于产品的开发。
Common functionality can be developed in a separate Platform branch, with each product getting its own branch for the product-specific development.
这是我读过的关于分支的最好的文章之一： 面对敏捷开发、极限编程、团队协作和并行发布时的分支和合并
我想我想避免耦合两个项目的分支（以及时间表）：所以，而不是您在其中编辑通用功能并编辑多个产品的单个分支，可能是以下两种替代方案之一：
1) 独立于任何产品开发通用功能
2) 使用一个产品开发通用功能
Here is IMO one of the best articles I've read about branching: Branching and merging in the face of agile development, extreme programming, team collaboration, and parallel releases
I think I'd want to avoid coupling the branches (and therefore the schedule) of two projects: and so, instead of a single branch in which you're editing common functionality and editing more than one product, perhaps one of the following two alternatives:
1) Develop the common functionality independently of any product
2) Develop the common functionality with one product
不是对你的问题的直接答案，因为我不能 100% 确定可以给出“一刀切”的答案。 但 Jeff 写了一篇关于分支的优秀博客文章。
Not a direct answer to your question, because I'm not 100% sure there is a "one size fits all" answer that can be given. But Jeff wrote an excellent blog post around branching.
在树的最高点处分枝。 IE，它应该包括所有项目的代码、共享模块……可能还包括文档/构建脚本/安装程序/等内容。 为什么？ 为什么不！ 到目前为止提到的所有系统（SVN、TFS、Perforce、git）中的分支都很便宜。
这种策略在使用“路径空间”分支的系统（TFS、Perforce）中尤其重要。 否则，生成在不同人员的工作空间中保持一致的完整产品套件的构建将成为维护的噩梦。
一旦将其付诸实践，您就可以在给定分支中随意修改尽可能多或尽可能少的代码库。 您始终可以进行完整构建来验证集成问题； 您仍然可以选择合并任何分支集之间的任何组件。 但SDLC 策略问题是完全正交的。 您可以按功能、按团队、按版本或上述任意组合进行分支； 您可以根据自己的喜好定义正向/反向积分标准。*每个分支恰好是一个超集这一事实在许多策略中都被证明是有利的，只要您的工具能够应对挑战，就永远不会成为一个缺点。
*选择策略是个人问题，取决于许多因素。 其他人建议了一些众所周知的文档来帮助您做出决定。 我将 Microsoft 的 TFS 指南 的最新版本放在那里与他们中最好的人一起。
Branch at the highest possible point in your tree. IE, it should include the code for all of your projects, shared modules...and probably things like documentation / build scripts / installers / etc as well. Why? Why not! Branches are cheap in all of the systems mentioned so far (SVN, TFS, Perforce, git).
This tactic is especially important in systems that use "path space" branching (TFS, Perforce). Otherwise, generating a build of the complete product suite that's consistent across different people's workspaces becomes a maintenance nightmare.
Once you've put this into practice, you're free to modify as much or as little of the codebase as you like in a given branch. You can always do a full build to verify integration issues; the option of merging any component(s) between any set of branches remains open to you. But the question of SDLC strategy is entirely orthogonal. You can branch per-feature, per-team, per-release or any combination of the above; you can define forward / reverse integration criteria however you like.* The fact that each branch happens to be a superset proves advantageous in many strategies, and should never be a con so long as your tools are up to the challenge.
*Picking a strategy is an individual matter that depends on lots of factors. Others have suggested some well known docs that help you decide. I'd put the most recent revision of Microsoft's TFS guidance up there with the best of them.
将它们全部放在一个分支中。 您想在开发时知道产品 A 的更改是否会破坏产品 B。这比您发现 ProductB 必须按原样重写您的其他 3 个所依赖的通用代码库的一半时陷入合并混乱要好得多。
编辑：为了澄清，我的意思是他们都应该共享一个开发分支。 我建议使用单独的生产分支来代表生产中的代码，如果您定期发布错误修复版本，则建议使用维护分支。
Put them all in one branch. You want to know at development time if a change in product A breaks product B. This is much better than getting into a merge mess when you discover that ProductB had to rewrite half of your common codebase your other 3 depend on as-is.
EDIT: To clarify, I mean they should all share a development branch. I would advise a separate Production branch to represent the code that is in production, and a Maintenance branch if you do regular bugfix releases.
我们也有类似的情况。 我们有用于日志记录、数据访问和安全性的通用库，但这些库在多个项目中使用。 我们所做的是为每个产品创建一组单独的分支，然后使用 SVN 外部链接到公共库。 因此，公共库被维护在所有项目的“共享”分支中，而所有项目本身都有独立的分支。
这样我们就可以确保所有产品都是针对最新版本的公共库构建的，同时项目也能够独立维护。
We have a similar scenario. We have common libraries for logging, data access and security but these libraries are used across multiple projects. What we do is create a separate set of branches for each product and then use SVN externals to link to the common libraries. So the common libraries are maintained in a "shared" branch across all projects, whilst all the projects themselves have independent branches.
This way we can ensure that all products are building against the latest version of the common libraries, whilst the projects are also able to maintained independently.
我们通过将其构建为一系列分支，使用 git 构建了一系列具有共同基础和大量自定义代码的网站。
主分支包含核心代码，该主分支的每个分支都是核心的特定定制。 对核心进行更改时，可以轻松地将它们推送到分支，同时保持每个自定义版本的隔离。
18 个站点，一个 7 人团队历时 12 个多月的项目，仍然得到很好的控制！
We built a series of sites that have a common base and a large amount of custom code using git by structuring it as a series of branches.
The master branch contained the core code, and each branch of that master was a specific customisation of the core. When making changes to the core, it was easy to push them down to the branches, while keeping each custom version isolated.
18 sites, and a 12+ month project with a team of 7, and it's still well under control!