Using sourcetree/bitbucket how can I manage multiple projects using a common codebase?

Question

I have made a few libraries that different projects use.

When I make changes to projects, I sometimes make changes to the codebase, and I want to be able to manage this all through sourcetree.

So, for example, I have a project with global.js and project1.js. I also have another project with global.js and project2.js.

I never want to merge project2.js with project1 and vice-versa, however, any changes I make to global.js in either project, I want to be able to merge.

As this is work for separate companies, it is important that the code is never brought across to the wrong project.

This is obviously quite a simple example, however, in reality there are many files to deal with.

For these particular projects, the changes to each individual project is stored in subfolders to keep the project specific code separate to the global code.

eg: codebase/includes/global.js etc..

codebase/modules/project1 or codebase/modules/project2

What is the recommended way of managing this using sourcetree/bitbucket?

Answer 1

The usual way is using whatever is common for distributing libraries in the eco system for your language. For C# publish a nuget package. For Java look into how maven downloads packages. For ruby publish a ruby gem. For python distribute a module. For perl look into cpan etc. In your code just refer to whatever you publish and your code is essentially on par with any third party tools you are using.

Answer 2

Use a separate repository for your common codebase

The easiest way would be to manage the common code apart, in a separate repository.

Then you can use git submodules or git subtree to import your common code into the other repository.

Use packages instead of GIT merging to import the common codebase

Better still, Esben Skov Pedersen's answer gives a preview about package management. I personnally know well Maven in the Java world. In JavaScript, I think the two most widespread are Bower and NPM.

Choose the right granularity

The granularity is to be defined according to your needs. For instance, if your projects 1 and 2 have a large common codebase and project 3 shares only a subset of this common codebase, you could cut it out this way:

• common codebase imports minimal subset
• project 1 imports common codebase
• project 2 imports common codebase
• project 3 imports minimal subset

Adapt to your own needs.