使用GitHub维护不同硬件设置的不同版本代码库的最佳方法 [英] Best way to maintain different versions of codebase for different hardware setups with GitHub

查看:146
本文介绍了使用GitHub维护不同硬件设置的不同版本代码库的最佳方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是GitHub的新手,并且我所在小组的软件项目之一正在开发具有自定义硬件设置的界面.每个硬件设置都必须具有不同版本的代码库,但是我不确定GitHub的最佳实现方式.我可以为每个不同的设置创建一个分支,但是这种暗示意味着它们最终将被合并回主数据库.有没有其他人以前遇到过这个问题,或者知道处理这个问题的最佳方法?

解决方案

我不认为这与Git/GitHub特别相关,因为这不应该与特定的版本控制系统绑定.我宁愿从项目设置的角度来看这一点.

如果我正确理解您的问题,则说明您正在构建一个具有一些应在不同类型的平台上运行的核心功能的系统.每个目标平台都将运行不同的二进制文件.该二进制文件将包含在此目标平台上运行所需的核心功能和特性.

通常,人们倾向于使用分支来创建新功能或修复错误.在多平台环境中,这些错误修正和新功能应在目标平台所有上进行测试和部署.

这样的项目的一个很好的例子是 libgit2 %跨平台的纯C实现的Git核心方法.

该库可在Windows,Linux,MacOSX,Amiga等平台上运行,并且每个平台都有特定的要求(不同的64位数据模型,与文件系统,网络进行交互的不同API等). /p>

对于每个平台每个区域都需要特定代码的区域,该项目定义了一些与核心功能进行交互的接口.然后针对每个平台在不同的源文件中实现这些接口.在构建时,将根据选定的目标平台将特定的源文件与核心文件打包在一起.

为了实现这一目标,该项目依赖于 CMake 能够构建VisualStudio项目(针对Windows)或gcc(或clang)(用于* nix). CMake的工作方式是应用 CMakeList.txt 文件中描述的项目食谱",该项目描述要包括的文件,要定义的编译器宏,...

最重要的是,为了确保一切正常,将项目挂接到了Continuous Integration服务器上,该服务器构建二进制文件并在每个不同的目标配置上运行测试.在GitHub上工作时,Travis CI(开源项目免费)是一个不错的选择(TeamCity也很好地集成了).配置它以在所有(或子集)分支上自动构建并运行测试非常容易.而且,每个Pull请求也会自动进行测试!

FWIW,这种好处不限于C.例如, LibGit2Sharp /.net的libgit2绑定使用类似的概念,并利用Travis和TeamCity来确保所有测试都在Debug和Release版本中通过.Net/Win32,.Net/Win64和Mono/Linux.

摘要:

  • 请勿将分支机构用于平台.
  • 将分支用于新功能和错误修复
  • 用单元测试覆盖您的代码(确保这些测试也可以执行平台特定的代码)
  • 使用CI服务器确保所有目标平台上的所有内容都能正常构建/运行

一些资源可以进一步激发灵感:

I'm new to GitHub, and one of the software projects my group is working on interfaces with custom hardware setups. It is necessary to have a different version of the codebase for each hardware setup, but I'm a bit unsure of the best way to do this with GitHub. I could create a branch for each different setup, but that sort of implies that they will eventually be merged back into the master. Has anybody else come across this before, or know of the best way to handle this?

解决方案

I don't think this is related to Git/GitHub in particular, in the sense that this shouldn't be tied to a specific version control system. I rather see this from a project setup perspective.

If I correctly understand your question, you're building a system with some core functionalities that should run on different kind of platforms. And each target platform will be running a different binary. This binary will contain the core functionalities and the specificities required to run on this target platform.

Usually, one tend to use branches to create new functionalities or fix bugs. In a multiplatform context, those bugfixes and new functionalities should be tested and deployed on all the target platforms.

A very good example of such a project is libgit2 which is a 100% cross-platform pure C implementation of the Git core methods.

This library runs on Windows, Linux, MacOSX, Amiga, ... And each of those platforms have specific requirements (Different 64-bit data models, different APIs to interact with the filesystem, network, ...).

For each area that requires a specific code per platform, the project defines some interfaces that the core functionalities interact with. Those interfaces are then implemented for each platform, in different source files. At build time, the specific source files are packaged along with the core ones according to the selected target platform.

In order to achieve this, the project relies on CMake, which is able to build a VisualStudio project (when targetting Windows), or a gcc (or clang) one (for *nix). The way CMake works is by applying a project "recipe" described in a CMakeList.txt file which describes what file to include, what compiler macros to define, ...

On top on this, in order to make sure that everything works ok, the project is hooked on a Continuous Integration server which builds the binaries and run the tests on each different target configuration. When working on GitHub, Travis CI (free for open source project) is a good choice (TeamCity is also pretty well integrated). It's quite easy to configure it to automatically build and run the tests on all (or a subset) of your branches. Moreover, each Pull request is automatically tested as well!

FWIW, This goodness is not limited to C. For instance, LibGit2Sharp, the Mono/.Net bindings of libgit2 use similar concepts and leverage both Travis and TeamCity to make sure all the tests pass on .Net/Win32, .Net/Win64 and Mono/Linux, in Debug and Release versions.

In summary:

  • Do not use branches for platform specifcities.
  • Use branches for new features and bug fixes
  • Cover your code with unit tests (making sure that those tests also exercize the platform specific code)
  • Use a CI server to ensure that everything build/runs ok on all your target platforms

Some resources for further inspiration:

这篇关于使用GitHub维护不同硬件设置的不同版本代码库的最佳方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆