We are using GIT as our version control and I'm no expert at it. So recently I got asked by another developer to remove all the contents of a repository and leave it blank so he could upload a new application (by new application I mean the solution and code is different, but the idea of the application is the same, it will do exactly the same, just got rebuild), what I told him was to remove all the files, commit and push, then add the new application, commit and push again, so we could have a history as to what happened to the old application, but I was wondering if what I did was correct? or it should had been better to archive the repository and create a new bare one, I read on this Post that GIT has some orphan branches, but I think this is not our case, since there will be no more development, bug fixing, etc. on the old branch, so what are your thoughts on what to do or best practices that exist and we don't know of, thank you in advance for your responses and comments.
-
1If it is a new application it should be in a new git-repository. I don't see a benefit from hijacking the repository but some downsides like mixed histories, bigger repository size and so on. – RonaldFindling Jun 01 '17 at 22:33
-
The application is in theory is the same, by new application I mean, a complete different solution, started from scratch, the code itself is new, but the idea of the application is the same. – Mario Jun 01 '17 at 22:40
4 Answers
If you are going to use a public repository (i.e., not setting it to private), I don't see the issue with creating a new repository for the application.
That way you have the old version still there and a clean repository for the new application.
If you really want to replace the current project in the repo, there are possible ways of doing this. I have attached a link to another stack overflow question where they go in more detail about this.
Replace GitHub repository with a new Android Studio project while preserving old commits
Although this one refers to an Android Studio project specifically, the steps should still work for you.
EDIT (After seeing the update to your question):
It sounds like you are mainly modifying the code within the same files. If that is the case, then why not just make it a new commit, overwriting the old content of the files, but preserving the commit history?
- 1,952
- 2
- 11
- 12
-
For what I understood on that post, is basically what I told the other developer to do, remove files, commit and then add new files and commit and push – Mario Jun 01 '17 at 22:50
-
If that is the approach you would like to take, then I would say you had the right mindset and approach. Personally, I would create a new repository to upload the new application to. – Kurt King Jun 01 '17 at 22:57
-
-
I added an edit to my original response. I guess I am having a hard time understanding what all changed about the project structure. Were files renamed? Was the project structure reorganized? If you have just made changes to the code within the files, then commit the new changes? – Kurt King Jun 01 '17 at 23:10
-
Yeah, sorry, I edited my post, my wording was bad when I said that the application has nothing to do with the old one, what I meant was that the code itself has nothing to do, is new code, structure, solution, etc. but the application does the same. – Mario Jun 01 '17 at 23:12
-
Okay. So the directions you told him to follow by deleting the files, making a commit, uploading the new files, and then committing them was the right approach with that scenario. Just remember not to delete the .git folder. However, I would still personally create a new repository. That way you can move forward with the new repository with the chance to reference the old code if needed. This also gives you the option to delete the old repository when you are ready to do so. – Kurt King Jun 01 '17 at 23:17
-
If your new dev tree has nothing to do with old one I think better way is just to create new repository. Or if its not acceptable for some reason you can create tag as new initial point and strat from there (probably not good idea). Removing history and all data is not good and its really hard to truly delete all things from git
- 1,484
- 8
- 13
-
It is acceptable, I just came up with that answer because I thought it would be better to keep the history of what happened. – Mario Jun 01 '17 at 22:39
-
Its always better to save history if you can and its not cost so match – Alex Lyalka Jun 01 '17 at 22:43
-
And I've edited my post, what I meant was that the application code is new, it does the same things that the old application, but it doesn't have the same code at all, my apologies for the bad wording – Mario Jun 01 '17 at 22:52
he could upload a new application that had nothing to do with the old one
If the new application nothing to do with old one - then mixing the histories is not a good idea.
so we could have a history as to what happened to the old application
If you need a history of the old application, just keep it safe in old repository and create the new application in a new repository.
- 6,881
- 10
- 46
- 64
-
Sorry, was wrong of me to put it has nothing to do with the old one, bad wording selected, I've edited my post, by new application I mean, a complete different solution, started from scratch, the code itself is new, but the idea of the application is the same. – Mario Jun 01 '17 at 22:47
I would create an orphan branch, remove all previous code and add the new code. Then it would be 2 branches on the same repo: approachA, approachB.
- 26,375
- 3
- 36
- 60
-
Even if there is no actual need to do changes on the old application code? – Mario Jun 02 '17 at 00:01
-
You can keep it for "historical purposes".... and then you can get rid of the branch when you feel like it. It's _your_ repo, you can do as you please. – eftshift0 Jun 02 '17 at 00:05