Just a quick answer: I've seen some teams who have tried employing this 
"one branch for each customer" strategy.

While this might seem like a good idea in the beginning, down the road 
there are always wishes to merge features that have been developed for one 
customer with others. In the beginning, these merges are easy, but as time 
goes on, more and more conflicts arise, since the various 
branches/customers' custom changes will eventually collide with each other.

These features per customers strategy is better solved by a modular build- 
or plugin system. It's not something you should handle in your 
source-control system.

Just my opinion though, if someone has successfully managed such a 
strategy, I'd love to hear about it.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to