How do I structure a git repositories for a Product?

[Deepak KS]

Hi  

We have a software product, with 15-compnents and each of the 15-components have at least 15-modules.

Earlier a sys admin guy had configured the Stash server for us.

The current setup is like this:

1. Our Engineer had created 15-Projects in stash/bitbucket server for 15-Components
2. For each of the 15-modules in a given component, a individual repository is created
3. Thus we have around 225 + 25(for additional module), totally 250 repositories to manage
4. Individual developers creates their feature branches on their respective repositories and merge them to their production branch after release.
5. Feature branches gets created only on a particular module in a particular repository which is getting affected for that feature.
6. If a developer is working on a feature, which is affecting 10-modules, this developer creates a branch in each of the repository of the affected module. Thus he created 10-branches for a given feature.

In this way, we have many teams working on many individual repositories corresponding to their module. Packages are made from each of the individual repository and delivered to our infra team, who deploys the product on our hosted servers.

Since source is spread all over the place, there is no baselines/tags created for this product. Also managing these many repositories by a single CM admin is too much to handle.

 As a CM admin, I’m thinking of suggesting this structure for this product.

1. Create a single Project (Project A) in Stash 
2. Create a single repository (Repo A ) in this project 
3. Create a folder for each Component, i.e 15-Folders, under the repository root 
4. (i.e Project A - /RepoA/Component1/Module1 Module2 ……Module15
5. /RepoA/Component2/Module1 Module2 ……Module15
6. /RepoA/Component3/Module1 Module2 ……Module15
7. :
8. :
9. /RepoA/Folder15/Module1 Module2 ……Module15)

In this way we’ll have single repository to handle and CM admin will create branches and developers will just make changes and commit their code.

The issue here is, we are using Git repositories, developers do not want to clone the entire repository and permissions for these repositories should be managed at folder level, so that a team has access to only their modules.

I would like to hear lots of inputs from you ladies and gentlemen. Please feel to comment/suggest and advice.

Thanks a lot.

Regards

DK

[Tim Crall]

I'm not sure you can have all your "wants" at the same time.  You have to explore submodules, which may get you closer than anything else - but I haven't played with them much.

I'd suggest revisiting some of your assumptions.  Why do you have to manage at the folder level?  You cannot do this in Git, so if it's a requirement, you will have to make each of those folders a separate repo, at the least.  But since you can lock down branches, such as the master branch, so that only authorized people can merge, there shouldn't necessarily be a need to restrict permissions by folder, unless you can't trust your developers with read access to other teams' code.  Which seems odd.

Cloning an entire repo shouldn't be so bad because it's a one time thing...after that, you'd only be pulling updates.

[Deepak KS]

Hi Tim,

Thanks a lot for your valuable inputs.

I do understand that, we cannot manage permissions for code at folder's level in git. But that was the expectation from the dev team. I wanted to explore the other possibilities if any.

Since we already have 250+ repos and  and 1 CM guy, it is going to be messy. Thus we thought to consolidate all repositories into one, as it is one single product.

Yes, as you mentioned the master will be locked and only CM admin + 1 or 2 dev leads will have the access to merge into Master line.

Even I'm on same lines, cloning the entire repo is just a one time activity, later all we have do is pull and then push.

Best Regards,

Deepak.