Efficient project architecture with git

Question

Firstly, let me introduce general architecture of a project.

It is hierarchical. We develop server application for our customers. It is stored on main server.

Say, local server 1, local server 2, ..., local server n are the servers (main application instances) in different companies. Each company has one local server. Mostly all local servers have the same functionality (say, core module), but each company can have it's own. As an idea it was decided to solve this problem via git branching.

Let's consider some cases.

Case 1
One company (local server x) wants some specific feature that is needed only in that company. Following the logic our of idea of branches we do the following steps:

1. create git branch on main server
2. develop needed functionality for that server
3. create git branch (branch y) on local server x
4. push changes to main server
5. switch branch y on local server x
6. switch to master branch on main server

Case 2
We developed some functionality (changes in core module) that is common to all companies

Case 3
We developed some functionality that is common only to some companies

Want to hear your advises about how to solve "Case 2" and "Case 3".

Answer 1

Technically, @VonC is correct in saying that branches would be the way to go.

There is a caveat though. You're mixing 2 different paradigms here. SCM (git is a tool) means managing source code and its different versions.

Enabling/disabling product features is product management. Essentially, it boils down to development and deployment of your application.

What you're trying to do is combine feature management of your product with version management.

It is certainly doable (via SCM alone) and depending on your requirements, it may actually work well for you.

However, over a period of time, you'll end up in a branching/merging soup. Not only will it increase time and effort to maintain and upkeep each branch (and keep the "main" and other "branches" in sync), it'll also be counterproductive as every time there is change or new feature, you spend more time on planning on how to keep your branches up-to-date than the actual feature. This gets compounded over time with new hires who have no prior knowledge of your branch management techniques and if you end up having distributed teams who might want to create their own branch for a variety of reasons.

If I may suggest, keep one version of your application and implement a mechanism to enable/disable "features". This will make your SCM easier to understand, cleaner to implement and maintain.

A middle ground is to have core branch for the core module and then each submodule or feature is its separate branch. Anyone can install core module and as per need/permission, they can go and install separate "features" from their respective branches.

Hope this provides some clarity. If you have any questions, I'll be happy to elaborate on them.

Answer 2

I generally agree with Mrchief.

Additionally I would like to mention that git branches are best used in one of these three situations:

• Develop a feature on a separate branch and merge it into mainline when its done.
• Maintain an older version with bug fixes or security fixes
• Back port features of the current version to an older release

In the long run you should either plan to merge your branches back into the master branch or discontinue them. It is not a particularly good idea to have many branches running side to side to each other a long time because sooner or later they will diverge from the master branch (and from each other) and it will be very difficult to ensure that bug fixes or security fixes are applied on all branches.