Managing several threads of the same project in GIT

Hello,

I've been studying GIT for some time already, but still have not figured out if it can be used for the scenario like this:

for example:

I have a project, which divides to threads aiming to different clients most of the code in the project is shared between the threads in certain files there are different code parts to meet client requirements but even those files share the rest of the code

What I need to be able to do is:
- to get code for any thread I like at any time
- to be able to develop each thread separately
- to be able to merge certain changes from one thread to another, at the same
time without loosing the changes specific to the thread, and keep track of merge
history

With GIT strategy to treat content as a single unity - if you will try to merge branches - everything will be merged thus overwriting the changes that need to stay. But in the example above, if I make a change in the shared code in one thread, I need to be able to populate this change to all the threads, but this change only.

so - is this possible in GIT and if yes - what kind of strategy should be used?

thanks 

2008/12/26 pggrd <git@paggard.com>:

I suppose what you call threads are branches in git.

Git works best with convergent branches, so all branches should have more or less the same code.

What you can do is to have different configuration for each client (or Makefile variables), in the same way git supports different architectures, different sha1 implementations, etc. All the code is there and you just choose which one to use.

Santi

On 2008-12-26, pggrd <git@paggard.com> wrote:

How different are the chunks of code per client? A few minor differences, or large chunks of code?

Seems largely the same as maintaining an older release and backporting changes from the main trunk to it (or sometimes the other direction), while keeping them distinct. Which happens all the time...

However, a maint release eventually atrophies -- changes stop coming in, and eventually your last customer using it has upgraded and the branch becomes unused.

You can't do that with your "client branch", so eventually this will start diverging further and further from the trunk.

The way to mitigate that is to have your main trunk contain only the stuff that is common to *all* your clients, and let each client branch maintain differences from this. So in effect, those "topic branches" are never getting merged back to the mainline. When you make changes that should go to every client, you make them on the master and merge them into the "topic branch" (your client branch). When you want a commit from client A to be used for client B, you cherry-pick (cherry-pick from within gitk is pretty neat for occasional, manual, cherry picks).

The only caveat I see is that once in a while you'll want to just rebase each client branch against the master just for sanity. This should be done on one repository, and be a coordinated thing so that all the developers who're working on that particular client branch can re-fetch. You might end up doing this once in a few months so it's not bad I guess.

Sitaram

PS: I think all this will work, but others with more
experience need to weigh in... it's always a bad idea to ask
questions during the holidays, you never know who's manning
the support lines ;-)

PPS: As Santi said in the other reply, you should also
consider making these changes part of a single code base,
with some sort of configuration deciding what actually gets
done.  Would be cleaner in the long run I guess...