问题
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?
回答1:
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:
- libgit2 repository
- Cmake build recipe
- Travis CI configuration file
- A example of a pull request with platform specific code along with the matching Travis build log
回答2:
I don't know about a "best" way to handle this, but I would probably have one branch, e.g. core, where all non-platform-specific work is done, and then the additional branches for each platform. The platform branches would have to periodically merge core in to get new functionality, but they would never be merged into anything. You could also do that with whole repositories instead of branches - one core repository that's completely generic, and specific separate repositories for each platform that fetch from the core one but never push back.
来源：https://stackoverflow.com/questions/17328714/best-way-to-maintain-different-versions-of-codebase-for-different-hardware-setup