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.
8 Comments
canpolat@programming.dev · 6 pts · 3y
Not sure I got the question right, but it sounds like you can benefit from code reuse via shared projects or packaging different parts of the code into chunks.
nieceandtows@programming.dev · 2 pts · 3y
That’s a good idea to think about, thank you
verstra@programming.dev · 3 pts · 3y
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.
nieceandtows@programming.dev · 1 pts · 3y
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
verstra@programming.dev · 2 pts · 3y
Oh manually copying is worse than the other three options, because it will not retain the history of commits
tiny_fingers@programming.dev · 2 pts · 3y
If the changes in one app will never be pulled into the other, completely separated would probably be fine but I’d personally just fork it due to sheer laziness.