On Tuesday, February 26, 2013 11:51:01 AM UTC+1, Vasiliy Tzukanov wrote:
> Hi guys,
> We are using git routinely in our project to allow collaboration of
> employees from all around the world. Until now, we supported just a single
> client, but there are new clients for our project now, each having slightly
> different requests.
> We need to figure out how can we manage few very similar projects in
> parallel, without having to manually enforce their coherency. We though of
> something like this:
> - A contributer chooses a branch to work on.
> - When the work is done the contributer has two choices:
> - To apply the changes to the branch he chose to work on - in this
> case the procedure is identical to our current flow
> - To apply the changes to all the branches - in this case the
> contributer will be asked to resolve merge conflicts for each branch
> My questions are:
> - Is this seems a reasonable approach?
> - Is there a way to achieve this behavior with standart set of Git
> - Any other suggestions/comments are more than welcome.
I think we've discussed this a few times on this list. It boils down to Git
branches not being a good abstraction for re-using functionality between
different customers. I've done some reasoning here:
Git branches are better suited for short-lived modifications - i.e. pull
requests that only live for a few days, or maintenance versions that have a
set end-of-life after a few weeks or months. If you want customer specific
"adaptions" that will go on to live indefinitely, it's probably better to
build this modularity into your software architecture, using a plugin
structure, a templating system, software factories, etc.
Beyond this it's very hard to advise anything concrete based on what we
know about your context.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.