Fork or Mirror existing git repository for a similar but different project?
Fork or Mirror existing git repository for a similar but different project?
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.
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.
6That’s a good idea to think about, thank you
2
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.
2Got 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
1Oh manually copying is worse than the other three options, because it will not retain the history of commits
2
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.
2