5
I have a question regarding the organization of GIT.
I have 1 project that will be divided into 2 verses for different clients, I would like to maintain a main branch and that the general changes were made in this branch and replicated for the 2 verses, but each version will have its only changes.
Ideally do with Fork or branches?
1
This is the kind of problem that a code versioner will not help you solve, what it helps is in parallelizing a software development work, but the goal will always be the branches go back to the main.
I would recommend you to look for a solution in architecture, such as making extensions or plug-ins, there are frameworks for that, in . Net exists the MEF, Managed Extensibility Framework and in this link you can know how it works and look for something similar to the platform you use.
1
You can use two distinct branches in the same repository. This way it will be more practical to keep the two versions separate when you need to make some changes that you want to apply to both branches through another branch, cherry-pick, etc..
However, do not recommend to do this with your project. Try to keep only one single version of your application. If customers have different needs, control this with different screens or permissions. If you continue with this idea, you will end up with two different applications and the code you want to apply to both will not work out so differently that the two applications have become one of the other. This will turn into a nightmare to keep.
I am witness to this hell of maintenance. It has been tried to do this of each client having its specific branch. At the time, we had about 20 to 30 clients in this scheme; of these, 3 survived in 4 separate branches (yes, one client has 2 branches) in which there is virtually no maintenance (and are infernal to maintain, when needed), 2 returned to the main branch and the rest was canceled. Among the reasons for the cancellations was software instability
@Jeffersonquesado, at first it always seems like a good idea. Initially you avoid the problem of managing in the same application the distinct Features, and everything looks good and things flow well. But after a while the fate of this solution is always chaos, hehehehe
Browser other questions tagged git github versioning bitbucket
You are not signed in. Login or sign up in order to post.
I would say that the ideal would be to have a configuration that would follow path A or path B, having two separate source codes can give you a lot of headache (own experience)
– Jefferson Quesado
But then every improvement I’ll have to replicate for N projects, I don’t think it’s smart that. The product is the same, we only have 2 slightly different versions for specific customers.
– RBoschini
Depending on the number of project files that would change for each client, if there are few I believe that using branch can be the fastest and simplest solution. But Fork is the copy of a base project that can be changed freely that in its context seems to be more interesting, even more so if in the future you use the base project for new clients.
– Andre Gusmao
André is my thought, there would be 1 base product with 2 variants for each customer, qlq Generica change is made at the base and replicated for the others. sera is the best way to solve this problem?
– RBoschini
@Rboschini, I think the best way would be for the base project to be designed to accept parameterizations as well as Wordpress and other CMS works. Another way to do it is to develop the base project in a generic way and the variants would have the base project as dependency.
– Andre Gusmao
It would not help, it is an Ecommerce and the biggest variation will be of layout and not of business rules. the api will remain the same, only the front will follow a base that will branch into 2 slightly similar verses. Parameterizing this would not be the best way in this case.
– RBoschini
I ended up solving creating Fork and making Sync with precise qd base project.
– RBoschini