I am trying to set a proper branching strategy for an application that is structured as below.

Following is the directory structure of the application

|______SuperApp
|          |______CommonCode
|          |
|          |______App1
|          |
|          |______App2
|
|_____ InfraStructureCode

SuperApp consist of multiple micro apps that can be developed / worked independently as long as Common Code and infrastructure code directories are present.

The constraint we wanna put in place is ,

i) Developers working on a specific app (Say App1) should not have access to push changes related common code or infrastructure code.

Currently we achieve this using

git update-index --skip-worktree <DirectorytoSKIP>

ii) Maintain certain level of atomicity between each apps like App1 , App2 etc.,

(i.e.,) currently if we create a new branch from develop , to add a new feature in say App1 , all the other apps directory( App2 , App3) also will get included.

So to maintain atomicity is there a better branching strategy ?

Ideally , we would want a feature branch to have only common code , infrastructure code and the particular micro apps (App1) which is being developed.

However in master branch or release branch we wanted to maintain the entire application ( like the directory structure as shown above).

CodePudding user response：

Branches are for isolating a development effort on one or several Git repositories.
Not on "part of a Git repository".

You need one Git repository per module (app, common, lib), which allows you to compose them as you need using submodules.

For each parent repository using said submodules, you will be able to apply the branch strategy you want, without worrying about "hiding" certain subfolders.