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 https://groups.google.com/d/msg/git-users/-/gKhB6o3Kc54J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
