Hi Thomas, I looked through few pages on the forum and found few similar topics, but each time the details vary. We don't want to use language constructs because our project is written in Verilog, and it becomes very cumbersome to maintain these constructs and to perform future debug and adaptations once you start using them. Ok, branching is not a good solution. Can you think of a way to set up two separate repositories, but which get (conditionally) merged each time one of them changes? Thanks Vasiliy
вторник, 26 февраля 2013 г., 15:07:41 UTC+2 пользователь Thomas Ferris Nicolaisen написал: > 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 >> independently >> >> My questions are: >> >> - Is this seems a reasonable approach? >> - Is there a way to achieve this behavior with standart set of Git >> command? >> - Any other suggestions/comments are more than welcome. >> >> Thanks >> Vasiliy >> > > 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: > > https://groups.google.com/d/msg/git-users/TRnyF1UJfMc/gKhB6o3Kc54J > > 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.