1

At my work we have multiple products.. productA, productB, ... these products reference multiple components. componentA, componentB.. there are also shared components sharedA, sharedB... etc.. which are either shared by multiple components, multiple products or by a product and a component.

We are currently moving all these things to separate Git repositories however, we have a hard time find a way to set up repositories in such a way that everything stays manageable.

We have two problems that make setting up repositories hard.

  1. There are a lot of hard dependencies. When I want to work on ProductA I need to have the source code for ProductA, componentA, componentB, and sharedComponentC on my computer, since I might be changing code in all of them. For ProductB I need componentA, sharedComponentC and... this makes it hard to choose what to store in what repository.

  2. Say componentA is an interface library, this interface library is used by ProductA and ProductB. For ProductA it needs to work normally but in ProductB it needs to show an extra button. We have a lot of these very small differences in components should we make a branch per product and sometimes integrate the branches to make sure they have the same new features? Maybe develop on a 'general' branch and push changes to each 'small difference' branch? Is it bad to have a lot of active branches in a project?

Are there any rules of thumb that help to decide how to split software over multiple repositories? What are good ways to work on software that is in multiple repositories, or tooling that helps in this regard? What is proper repository set-up for components with a lot of small differences? In the end these are all the same question. What is a good repository strategy for multiple interconnected components with small differences?

Some more information that might help. We develop solely on Windows, 99% of the code we write is C#, the other 1% is C++/CLI. All our developers have access to Visual Studio 2013 Pro. We are willing to buy software to help us with this problem but we are a small company so we do not have infinite budget :).

Of course a part of the problems we are having are due to (bad) design decisions in the past. (No design decision can completely safeguard against the future development of your software/company ;) ) We are working on changing that. But for the time being we would like to decide on a modern repository strategy that makes things a bit more manageable.

Improve this question
4
  • 1
    How about using nuget, so every time core component changes other developer just need to fire nuget to get latest component
    – kirie
    Commented Feb 4, 2015 at 8:56
  • @kirie we are using nuget for the more stand-alone components. However, we're not sure what to do with the more intertwined components, again we need some way to choose separation. Also slightly different versions is a bit of a problem. Another drawback of nuget is that when working on a product and library at the same time the iteration time skyrockets.
    – Roy T.
    Commented Feb 4, 2015 at 9:12
  • It sounds like your components may be too tightly coupled. Try making the interface between them more abstract, at which point nuget should be able to handle everything.
    – Jules
    Commented Feb 4, 2015 at 9:55
  • If I change the interface in/of a component because I'm developing a new feature I'll need to publish a new pre-release package, install the new package for the product, test/integrate the functionality in the product and then repeat all these steps for the next change. While normally I would only have to do compile->test->change.
    – Roy T.
    Commented Feb 4, 2015 at 10:04

1 Answer 1

Reset to default
2

With git you can use git submodule.

ProductA can have specific commit_ids (which can be a branch) of some submodules (for example ComponentA, ComponentB, SharedComponentC).

To add a component to ProductA, from the ProductA directory on your development machine do:

C:\projects\ProductA.git\> git submodule add --branch master --name ComponentA http://reposerver.ourcompany.com/ComponentA components/ComponentA
C:\projects\ProductA.git\> git submodule add --branch master --name ComponentB http://reposerver.ourcompany.com/ComponentB components/ComponentB
C:\projects\ProductA.git\> git submodule add --branch ProjectA --name sharedComponentC http://reposerver.ourcompany.com/ComponentC components/sharedComponentC

Other developers can use:

C:\projects\ProductA.git\> git submodule init
C:\projects\ProductA.git\> git submodule update

to receive the correct versions of the submodules in their working directory.

When you make some changes to a submodule, you commit the changes of the submodule and you commit the new version of the submodule in the project, i.e.:

C:\projects\ProductA.git\components\sharedComponentC\> git add ...
C:\projects\ProductA.git\components\sharedComponentC\> git commit
C:\projects\ProductA.git\components\sharedComponentC\> cd ..\..
C:\projects\ProductA.git\> git add components/sharedComponent
C:\projects\ProductA.git\> git commit

Remarks

  • I used command-line syntax to explain how to use git; you are free to use any graphical tool or visual studio plugin that you like.
  • I checked the syntax and parameters under Linux and translated the examples to Windows command prompt, so there might some mistakes (e.g. slashes instead of dashes); refer to the git reference manual for the exact syntax.
  • The project directory (C:\projects\ProductA.git), branch name (ComponentA), repository location (http://reposerver.ourcompany.com/ComponentA), and submodule directory (components/ComponentA) can vary independently.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.