Managing several threads of the same project in GIT

Managing several threads of the same project in GIT

[pggrd]

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 

Re: Managing several threads of the same project in GIT

[Santi Béjar]

2008/12/26 pggrd <git@paggard.com>:
> 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

I suppose what you call threads are branches in git.

> 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
>

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

Re: Managing several threads of the same project in GIT

[Sitaram Chamarty]

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

> 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

How different are the chunks of code per client?  A few
minor differences, or large chunks of 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.

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...