Search code examples
gitversion-controlrepositorygit-submodules

What are the possible GIT repository structure designs for a project like mine?

I am moving a project from SVN to GIT.
The project uses a set of SQL procedures. Multiple clients have their own versions of the files, but they also use a CORE set of procedures that is the same for all clients.

Currently what we have on SVN is a one folder containing a CORE folder and multiple folders containing client specific procedures (see "current folder structure" below).

My initial idea was to have one repository containing core files and separate branches that contain additional files per client, but then I realised that it can be quite dangerous and easily become messy if someone pushes files to the wrong branch.

So, my another idea was to have each client's procedures in their own repository and linking the CORE repository as a sub-module in each of them.

Questions:

  1. What are the possible repository structure designs (workflows?) I can use for this scenario?
  2. What are their advantages and disadvantages over the others?

Here is some additional info that can make my current situation easier to understand:

Rules:

  • CORE is always the same for every client
  • Client folders contain their own additional/bespoke files/procedures
  • Only my team is making changes to the repository (i.e. clients do no have access to the code)
  • It can be usefull to easily pull changes from one clinet to another, but it is not a stric requirement.

Current deployment process at clients site:

  1. Clone an SVN repository containing all CORE files + ALL files for clients (see folder structure below)
  2. "Install" all the core procedures
  3. "Install" all the client's bespoke procedures

Current folder structure for the project:

├── core
│   ├── proc-core-bar.sql
│   ├── proc-core-csv.sql
│   ├── proc-core-db.sql
│   └── proc-core-foo.sql
├── client-1
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   └── proc-client-ordr.sql
├── client-2
│   ├── proc-client-addr-additional.sql
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   └── proc-client-ordr.sql
├── client-3
│   ├── proc-client-addr-additional.sql
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   └── proc-client-ordr.sql
├── client-4
│   ├── proc-client-addr.sql
│   ├── proc-client-msgs.sql
│   ├── proc-client-ordr-additional.sql
│   └── proc-client-ordr.sql
└── client-5
    ├── proc-client-addr.sql
    ├── proc-client-msgs.sql
    └── proc-client-ordr.sql
Solution

  • What are the possible repository structure designs (workflows?) I can use for this scenario?

    • Git submodules
    • Git subtrees
    • Git slave
    • Bit
    • Unrelated independent repos, data collected and combined by deploy tool only

    What are their advantages and disadvantages over the others?

    Git submodules

    Pro:

    • Modular repo

    Contra:

    • Being locked to a specific version of the outer repo
    • The lacking of effective merge management
    • The general notion that the Git repository itself doesn’t really know it’s now a multi-module repository
    • Big workflow changes

    Git subtrees

    Pro:

    • Modular repo
    • Fewer changes to the workflow
    • Subtrees sources files are stored in the repo

    Contra:

    • Changes to the workflow

    Git slave

    Pro:

    • Aside from one new file in the superproject, adjustments to .gitignore, and perhaps a few private config variables, does not affect your repositories.

    Contra:

    • ?

    Bit

    Pro:

    • Handles both source-code and dependencies across different projects and the granular component level

    Contra:

    • Node.js is needed