git practice: complete new version of an application [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I have a current version of an application in production that I control with GIT. Now I must start implementing a completely new version of that application. It will have no sources at all in common with the current one. And that new one will become the "master" one day.

in the meanwhile the current version is maintained and evolves.

How do you manage that with Git? I don't like the idea of creating a "version2" branch. because I think (correct me if I'm wrong) that this should be tag related.

I could create a new GIT repo, but that sounds to me as an overkill, and after all it will be confusing having two GIT repos for the same app.

I was thinking about forking, but forking suggest "starting from the existing"

Answer 1

What might be best here would be to create a new branch in the same repo, that has no relation with current sources. This way you start with a blank directory, but stay in the same repository. This feature is called "orphan branch", check this post to see how to use it.

Answer 2

If the two applications have absolutely no code in common, then they are not really the same application, but they probably just look similar. That said, it's perfectly fine to have two separate repositories. One is app and the other app2 (where app is the application name for example).

If there is no way you would ever want to share code between the two versions, it doesn't make sense to put them in the same repository. If you insist however, you can create an orphan branch and start coding app2 inside that.

As far as git operations are concerned, there is really no difference between the two methods. If you have two branches with no shared history, you can always divide them up in two separate repositories in the future. If you have two separate repositories, you can always put the two histories together as one repository in the future. So in short, this is not a life and death situation, pick one and if you didn't like it switch to the other.