How to handle multiple variants of a project in git?

I have a project X in a git repo. It that has features A,B,C,D.

I want to create a new, similar project YT, but with small variations. It will have Features A,B,D',E, where D' is very similar with D but with a few lines of code changed.

The project is a monolith, not very easy to seaparate features in different components.

How should I handle versioning so I can always change both projects in the future?

I was thinking of creating a new branch from project X and call it project Y. Then, in theory I will be able to still modify project X and merge the changes in project Y. I am not sure how well it would work with the feature C, which is deleted (will I always get merge conflicts?).

Git versioning

1946 views

XCS

👍

👀

Last edited on Sept. 27 2020 at 20:45

Best answer

I guess the answer depends on how exactly these "features" are implemented. Using the two X and Y branches seems like a good solution to start. How you can keep X and Y in sync depends on your exact needs.

You already mentioned merging the changes from X into Y periodically. In this case, any time you change feature C the merge will try to re-add those files to Y and you will get a merge conflict.

Another way to do this could be to use a rebase. This can work better if:

the changes made in Y on files also in X are relatively few.
the added feature E is indepented from any files in X
You can read more about rebasing here
Rebasing takes all the changes made in Y since it was split of from X and applies ("rebase") them again from the current X.

If you plan to change the same code in both X and Y, you will get merge conflicts in any case, and I don't think there are any nice solutions for this case.

Moritz Wanzenböck

👍

Last edited on Oct. 2 2020 at 20:42

How to handle multiple variants of a project in git?

1 Answer available