多平台项目存储库设计策略 [英] Strategies for multiplatform project repository design

问题描述

在处理多平台项目时，我正在寻找有关存储库布局/设计的策略.通常依赖项是:

I am looking for strategies regarding repository layout/design when dealing with multiplatform projects. Usually dependencies are:

• 项目具有单个名称/品牌
• 每个平台都有单独的源代码
• 平台代码共享公共资源
• 平台之间共享设计文档和其他文档

我已经尝试使用git进行以下操作:

I've already tried (using git) following:

解决方案A:

• 每个平台项目都位于其自己的目录中
• 向所有平台的 master 提交

优势:

• 干净的代码开发
• 不合并

缺点:

• 日志是一团糟，您通常需要在所有提交日志之前加上平台前缀
• 有时撤消提交是不可能的，或者非常困难/混乱

解决方案B:

• 每个平台都有自己的分支机构
• 释放版本库时，会在每个分支上执行rebase，然后合并到 master +标记

优势:

• 清洁日志:)
• 为发展目标而进行的清洁分离
• 较少冲突

缺点:

• 需要合并到 master
• 所有平台同时进行基础调整-合并到主服务器后地狱

我不愿意创建每个平台的存储库，因为共享资源可能很困难，或者可能需要其他可能容易出错的任务.

I am hesitant to create per-platform repository as sharing resources might be difficult or would require additional, possibly error-prone, tasks.

期待您的专业知识.

推荐答案

这似乎是一个扩大规模的问题.存储库通常包含一个项目.一个项目的多个部分可能共享一个实用程序模块，但是对于小型项目，其规模还不够大，无法考虑将实用程序模块作为其自己的实体进行分离.但是，一旦实用程序模块变大，或者如果需要共享几个独立的实体，则需要将其变成自己的(版本化)模块.

This seems to be a scale-up problem. A repository normally contains a single project. Several parts of one project might share a utility module, but for small projects, the scale is not large enough to consider separating out the utility module as its own entity. However, once the utility module gets "big" or if several independent entities that share it need to be separated out, it needs to become its own (versioned) module.

我的方法将是使用单独的存储库，具体取决于所涉及的代码量.我不确定您添加的任务是什么意思，尽管它是主要的重构.我要做的第一件事是将共享资源放入一个独立的存储库中，并将其发行版本作为(特定于版本的)依赖项合并到每个平台构建中.这使每个平台上的开发与单个共享资源版本脱钩.共享项目的每项更改都需要测试每个平台，现在您有了一条清晰的分界线.然后，您可以一次在每个项目中都有一个自己的存储库.

My approach would be to use separate repositories, depending on how much code is involved. I'm not sure what you mean by added tasks, although it is a major refactor. The first thing I would do is make the shared resources into a stand-alone repository, and incorporate releases of that as a (version-specific) dependency in each platform build. That decouples development on each platform from a single shared resource version. Every change to the shared project requires testing every platform anyway, now you have a clean dividing line. Then you can make each project there own repository one at a time.

如果要跨多个平台获得项目的共享版本"，则需要一个项目"作为该版本的构建代码的根.您可能也考虑将共享存储库用于该代码，但这会将共享代码的发布与项目的发布耦合在一起.如果您的代码已达到此复杂程度，您可能想要的只是另一个用于存储构建代码的元项目"的存储库.除非您有一个疯狂的大型项目组，否则多个项目的构建都可以驻留在一个存储库中，从而允许它们共享通用代码.同样的问题，但规模较小，只有一个存储库有效.请注意，所有这些假设都需要一定程度的自动化测试:)

If you want to have a "shared release" of a project across multiple platforms, you need a "project" that is the root for the build code for that. You might consider using the shared repository for that code too, but that couples releases of the shared code to releases of the project. What you likely want, if your code has reached this level of complexity, is yet another repository just for the "meta-project" that houses your build code. Unless you have a crazy-big group of projects to work with, the builds for multiple projects could all reside in one repository, allowing them to share common code. Same problem again, but with the small scale, a single repository works. Note, all this assumes some level of automated testing :)

我在多模块项目中的经验来自于使用perl和java.在perl中，通常使用CPAN的许多独立共享模块.在Java中，可以使用Apache Ivy或Maven处理模块化依赖项.我在一个具有公司顶级顶层项目和每个产品单独项目的环境中使用Maven(这取决于公司元项目).每个项目都可以自由执行所需的工作.从一个项目升级到两个或多个项目之间共享的代码将成为其自己的项目.一个特别大的项目最终被分解为几个项目，这些项目均继承自其自己的元项目".Maven和Ivy被构造为处理这种分层依赖关系.我们使用Jenkins/Hudson作为集成服务器，该服务器每天晚上自动检查跨项目的构建(假设在编写测试时没有人...幸...).一旦我们需要更改整个公司的网站.没问题，在公司元项目中对其进行了一次更改，并在每个项目的新版本中自动将其选中！

My experience with multi-module projects comes from using perl and java. In perl, using many independent shared modules from the CPAN is the norm. In java, modular dependencies can be handled using Apache Ivy or Maven. I used Maven in an environment that had a top level meta-project for the company and separate projects for each product (that depended on the company meta-project). Each project was free to do what it needed. Code escalated out of one project to be shared between two or more projects would become a project of its own. One particularly large project was eventually broken up into several projects all inheriting from its own "meta-project". Handling this kind of hierarchical dependency is what Maven and Ivy are built to do. We used Jenkins/Hudson as an integration server that checked cross-project builds every night automatically (assuming no-one shirked on writing tests...). Once we needed to change the website for the whole company. No problem, changed it once in the company meta-project and it was picked up automatically in the new release of every project!

这篇关于多平台项目存储库设计策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！