nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

repositories strategy

albertarnau

hi , In my organization we want to use Stash , but I have a problem that I don't know how to solve with Git. Right now we have several projects that share code between them. This shared code is stored in a folder called CommonObjects.

When a programmer works on project A, uses the folder projectA and the folder CommonObjects, if other programmer works on project B,uses the folder projectB and the folder CommonObjects.

That way when , some code in then CommonObjects folder is modified affects both projects automaticatly.

I don't know how to approach it in Git, because if I created three repositories ( projectA , projectB and CommonObjects) how can I focus branching strategy?

When the programmer needs to create a new branch for a code change that affects both folders, it will have to do in the two repositories? And two pull request? In that way the code will not be in the same place and will be difficult to review the changes.

How can I manage this?

Thanks

Albert Arnau

Accepted answers

Balázs Szakmáry

If it is OK for Team A and Team B to see each other's code, you could put all three in one repo, but I suspect you don't want this.
Otherwise the right thing to do is to create three repos and optionally map the CommonObjects as a submodule into the other two. This has several advantages and disadvantages, but it is completely feasible. Changes to CommonObjects would have to be like this:
1. Change CommonObjects in a feature branch, create and merge a pull request. (Or just commit directly to master/etc. in CommonObjects.)
2. In a feature branch of projectX, update the submodule ref to the merge commit of the pull request in CommonObjects and at the same time, update the code to use the new CommonObjects version. The submodule reference change is part of the pull request and gets merged together with the code that refers to it.

All comments

Balázs Szakmáry

If it is OK for Team A and Team B to see each other's code, you could put all three in one repo, but I suspect you don't want this.
Otherwise the right thing to do is to create three repos and optionally map the CommonObjects as a submodule into the other two. This has several advantages and disadvantages, but it is completely feasible. Changes to CommonObjects would have to be like this:
1. Change CommonObjects in a feature branch, create and merge a pull request. (Or just commit directly to master/etc. in CommonObjects.)
2. In a feature branch of projectX, update the submodule ref to the merge commit of the pull request in CommonObjects and at the same time, update the code to use the new CommonObjects version. The submodule reference change is part of the pull request and gets merged together with the code that refers to it.

albertarnau

Hello, where can I find moré information about submodules and how to manage them?

Balázs Szakmáry

If you just Google "git submodule": https://www.google.com/search?q=git+submodule , you can find plenty of explanations.

Ramiro P

Hi Albert, other approach will be to have the 3 repos and just work in them separately. So Team A and Team B will use the same CommonObjects module.

Steven F Behnke

(Hint: If @Balazs Szakmary answered your question you should mark him as Answer)

Ron Summers

Reusable (or common) code management is always a challenge and is always difficult to address and not taken into account by a lot of tools. This problem isn't unique to Stash and/or Git. You run into it no matter which tools you are using though some do better than others.

You have two separate issues here. One is software configuration management (what are all the parts I need to build something) and the other is your change management strategy.

One of the most straightforward strategies is that your common code is handled as an SCM item of its own with development schedules, releases, issue tracking, etc. Then the other projects consume it (which is a different thing) as something released to it as you might from some vendor provided item.

How to consume it is another matter and depending on whether you want your build system to collect the necessary parts (typically referred to as a manifest approach like android repo or maven build systems) or you want your SCM systems such as Git to do it using either sub-trees or sub-modules. There are pros and cons to all of these approaches.

Which approach for all of this may depend on the size of your teams and the organization of your company. If you can't have a single team working on the common code and want to have multiple teams making changes to common code, you are going to have more of a challenge in the change management strategy (and the branching strategy within the repo). This may also alter how you want to bring all of the code together (your SCM strategy).

In my opinion, you need to understand your strategy and development flow then implement that in the tools.

Balázs Szakmáry

If you do this, (depending on the language + platform) you might also be able to use the CommonObjects as a NuGet package https://www.nuget.org/ or something similar.