I have a repository on github for a project that deals with importing/processing/sending reports to clients. There is now talk of creating a similar application for a different set of users, without the import part, but multiple send parts. The existing code base already has 90% of what the new application needs (and some extra that is not needed for this new project).
Should I fork the existing project and make the new project, or should I use the ‘import project’ function on github to create a new project based on the old project, or use the commandline to mirror the old project into a new project, or something else?
In future, there might be more projects that build on top of one of these projects with their own customizations, so I’m looking for a good approach that I can leverage again in future.
Please advise.
There is little difference between the three options you mentioned.
The only difference I can think of is that if you fork a repo on github, it will keep track of that and list the new repo undef the forks of the original one.
Got it, thanks. In the past, in similar situations, I would usually just create a new blank repository and manually copy the files I need from the old repository. Just wanted to see if there is a better/proper way
Oh manually copying is worse than the other three options, because it will not retain the history of commits