Best practice for managing project variants in Git?

Question

I have to develop two Django projects which share 90% of the same code, but have some variations in several applications, templates and within the model itself.

I'm using Git for distributed source-control.

My requirements are that :

• common code for both projects is developed in one place (Project1's development environment)

• periodically this is merged into the development environment of the second project (Project2)

• the variations are not easily encapsulated within apps. (eg. there are apps. such as "profiles" which vary between Project1 and Project2 but for which there's also an ongoing common evolution)

• both Project1 and Project2 have public repositories, so that I can collaborate with others

• similarly Project1 and Project2 ought to have development, demo, staging and production servers.

• however, the public repository is not on the same server in both cases. So, for example, when I'm developing in Project1, I want to be able to "push" to my github server, but not have Project2 stuff going there.

• there are files such as local_settings.py which are completely different between Project1 and Project2, but should be shared between multiple developers of each Project

So what's the best way of managing this situation?

What would seem to be ideal would be something like a "filtered pull" where instead of .gitignore saying "ignore this file entirely", I can say "ignore this file when pulling from that repo" I couldn't see anything quite like that in the documentation, but might there be something like that?

Answer 1

Move the common code to its own library and make it a dependency of those two projects. This is not a question of version control, but a question of code reuse, design and eliminating duplication.