Is it a good idea to have two different GitHub branches that will never merge to store the interfaces and the complete application separately?

Question

For my Software Engineering class we have to develop a button-led application in Java(ie pressing the button toggles the LED). We have to define the overall architecture in terms of interfaces, and then implement it in a variety of scenarios: button and LED modeled as GUI elements on the same PC, button and LED modeled as GUI elements not running on the same machine(eg remotely), physical button and LED on a Raspberry Pi/Arduino etc...

Despite the changes in the running environment, the interfaces must be the same, ie only the implementation has to change. By interfaces I don't mean the GUIs, but the interfaces the classes in my application will implement(eg there's the interface iLed that will be implemented by the class Led, whose methods code will vary depending on how the LED is modeled: a physical LED, a local GUI element, etc..). Just to give you an idea, at the following link there's draw.io UML diagram of the interfaces(open it with draw.io): https://drive.google.com/file/d/0BxSY8GbXKYeAd0dZNm92ODdOSFE/view?usp=sharing

What I want to is to be able to switch back and forth between the interfaces(and the Driver stub) alone and the complete application I'm working on(which will have, besides the interfaces, the classes implementing them). What's the best way to structure the project to achieve this? Is it a good idea to have a GitHub repo with two branches that will never merge, one with nothing but the interfaces and the other one with the actual implementation(ie the complete application for a given execution environment, with the interfaces as well)? If not, what do you suggest? I'm asking because to my knowledge you usually branch off to add/modify some features and then merge back with the branch you initially branched off from, which means branches are meant to come back together.

Answer 1

Likely the best thing to do would be to make two separate repositories for your interfaces and your full application. Then, you can add the interface code into your main program as a submodule .

Essentially, a submodule is a way to keep a Git repository inside another Git repository. This way, you can work on the interfaces as a single independent project, but you can also include the code in other related projects that require it.